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PREFACE 


This manual is the first of three volumes dealing with the subject "Communications 
Processing Facility". | 


The Communications Overview Manual describes how the DPS 7 implements DSA concepts 
in the environment of both secondary and primary networks. It explains the rela- 
tionship between the Communications Network Configurator (CNC) commands and their 
associated DSA function. This manual is therefore intended to be used with the 
Network Generation Manual, which is the second volume of "'Communications Process- 
ing Facility". 

In the three volumes of "Communications Processing Facility", the term "64/DPS 7" 
is Synonymous with "DPS 7", the prefix "64" being a "carry-over" from previous re- 
leases. GCOS is used to designate DPS 7 software. 


The only public data network dealt with is TRANSPAC, which is the X25 packet 
switching network in France, and the use of which is contracted by PTT subscrip- 
tion. 


This manual is “intended for all peneonned of eh DPS 7 network processing ed 
ation in understanding the structure and function if their system. 


Section I describes the way that DSA relates to the DPS 7 system It explains how 

the DPS 7 distributes and implements the various DSA layers. It gives the corres- 

pondence between the network objects, Grcgnee by CNC, and GCOS communications com- 
ponents, and DSA elements. 7 


Section II defines the networking environment and gives an overall description of 
the GCOS communications components that support ite It relates these components to 
the principal DSA layers that they occupy, and gives a resumé of what these compo- 
nents do and how they interact with each other. 


Sections III and IV describe in detail the mechanism of establishing the network | 


connection, the tranSport connection and the logical connection between correspon- 
dents of the network. Each of the networks described, is related to the set of CNC 


commands for creating it. 


Section III deals with the networks accessed over the URP. It describes in detail 
the functions of the URP, BINS and TNS. 


Section IV deals with the networks accessed over the DN7100. It describes in de- 
tail the functions of the DN7100 and FNPS. 

Section V describes the services offered by DSAC and how it is architecturally 
implemented. It also treats the access provided by AUPI to administrative data in 
the DSA networks | 

Appendix A describes the TRANSPAC network and how its various components functione 
Each of the network objects concerning TRANSPAC are related to the CNC cCommanee 
and their associated parameterSe 


The following publications provide the relevant details to ad immediate Hétworib: 
ing environment 
© For a description of Distributed Systems Architecture 


- 38A4 9725 DSA Concepts 


° For references to the syntax and description of the CNC commands 


- 47A2 O02UC Network Generation 


° For the GCOS communications operator interface 
© 47A2 O4UC Terminal Operations 
- 47A2 05UC Network Control Operations 


° For a functional description of the DN7100 ~ 
_ 39A2 9808 DNS System Introduction . | 
° For starting-up and generating the network on the DN7100 


3 39A2 8024 DN7100 System Generation 


° For GCOS management of the DN7100 
» 47A2 O6UC Network Administrative Supplement | 


° nex a functional description of DSAC and details on the ASF log function 


© 47A2-15UC DSAC User Guide 


° For. a functional speci eiearion of AUPI 


, 47A2-16UC AUPI User Guide 
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SECTION I 


INTRODUCTION 


Distributed Systems Architecture (DSA) eee sney a functional model of Open Systems 
Interconnection (OSI). 


Being "open", such a networking model is flexible enough to keep pace with changes 
in technology and user demands. 


The advantages are twofold 
. firstly, the actual network processing is not visible to the user 


. and, secondly, the network itself can be more flexibly reconfigured. 
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THE ADVANTAGES OF LAYERED ARCHITECTURE 


The whole purpose of a network is to enable the user at a terminal to communicate 
with an application available and executing in any one of the configured systems. 


The less the user and the application are aware of the physical network, the more 
both EOP res eencenre can devote their.resources to actual data processing. 


In order to achieve this, DSA structures network services in layers, each of heh 
acts independently of the others, and is solely responsible for its own task. 


Each layer provides other layers the unconditional assurance that the data it 
transmits is error-free and in the same logical order as when received. 


The net result of such mutual reliance and cooperation between layers is that data 
reconstituted on reception is a facsimile of data when disassembled on emission. 


How the layer accomplishes its task is in the observance of its protocol which is 
a set of rules governing the processing and transmission of the data entity with 
which the layer is associated. Each layer has its own data entity oe its own pro- 
tocol. : 7 oo 


For as long as interconnected systems obServe a common norm, in this case the DSA 
Standard, layers of the same level can dialogue directly. 


The DSA standard ensures that the transmission of data from user to application, 
and vice versa, occurs with neither correspondent being aware of the physical com- 
ponents of the network between them or of the techniques used to maintain communi- 
cation. As far as the both correspondents are concerned, it is as though they were 
within the same site. 


eye 


Functional Example 


of 
Layered Architecture 


date entit ; = ; DSA layer 


system 1 | System 2 
message: application 


service 
nt+i1 


service 
n+1 


o? 
2 
& : of 
letter: session 
service Aidatolibesareh tiucatadenerdanenvhtceesieuats Service 
n | protocol 7 n 


fragment: transporty 


service | | service 
n-1 | n-1 


packet : network 


frame: data link 


service 
data transmission 
facility 
n- 2 


transport 
facility 
n- 1 


session 
facility 
n 


application 
facility 
n+ i 


This diagram identifies the principal DSA layers and their associated data enti- 
ties. The innermost rectangle represents the network link which is at the lowest 
layer, while the outermost rectangle represents the highest level of activity, 
representing the application and the user accessing ite 


Layers of the same level share a common Penene wreee tone the transfer of 
data and the access to successive layers. 


& A \ facility castles a ae of functions provided es a eae of service. 
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HOW DSA LAYERS ARE STRUCTURED 


Any communications architecture is concerned with three principal functions 

« processing data 

- and, inputting and outputting data between application and user, which involves 
- firstly establishing their connection 7 
- and secondly, maintaining and managing their communication. 


DSA layers are structured in the following way to implement these three functions. 


Information Processing 


Information processing is the highest level of all activities. It comprises the 
actual processing of data and the way that data is presented to both the applica- 
tion and the user. 


APPLICATION LAYER 


The application layer is concerned with data processing and is occupied by appli- 
cations, each of which is identifiable by its own mailbox within its system. 


In GCOS, applications are synonymous with "communications services" and are pack- 
aged products like IOF and TDS, and user-defined MCS applications. 


PRESENTATION LAYER 
The presentation layer provides a data transformation service so that 


» data input to the application is independent of the hardware characteristics of 
the real terminal 7 


. and, data output to the user is displayed in a "readable" format. 


In GCOS, the FORMS package comprising the utilities H_FORMGEN and H_FORMRTP is 
used to provide a formatting service for synchronous terminals in an IOF or a TDS 


environmente 


Message Management 


Message management is concerned with the interactive transmission of data between 
mailboxes, representing the application and the user accessing ite 


Both application and user have unique DSA addresses of the format s.m, where 
» s is the "session-name" and is unique throughout the network 
» and, .m is the 'mailbox-name'"' local to a system and unique only for that system. 


The presentation layer and the session layer implement message management. 


SESSION LAYER 


The session layer provides direct access between the ccrrespondents with neither 
being aware of the other's location, or of the communications path or mechanism 

used to ensure this access. However, if the correspondents are in different sys- 
tems, the session layer invokes communications management for the service provid- 


ed by the transport layer. 


Communications Management 


Communications management handles all functions involved in transpcerting data over 
a communications medium between systems in different physical locations. 


TRANSPORT LAYER 


The transport layer is the entry point into the communications network. It provides 
the connection independent of the medium over which the transport function is im- 
plemented. However, transport protocol options can be specified by the user to en- 
Sure the grade of transport service according to the type of application and the 
nature of the physical link. 


Each physical system has its own unique transport station through which all commu- 
nications pass. 


Transport Protocol Options 

Transport protocol options determine the techniques and rules for 
» transport negotiation 

« regulation of data traffic 

- and, data error recovery. 


In GCOS, these options are specified as arguments for the LEVEL parameter of the 
XPRTC command at network generation. 


The options, in the following increasing levels of functional importance, are 


» Level O: SLAVE 
The correspondent has no choice, not even to negotiate a connection 
Instead, the DPS 7 "local system'' imposes its own techniques and rules. 


- Level 1: BASIC 
The correspondent only has the right to connect to the DPS 7 "local 
system" but has no choice in selecting the techniques and rules. 


» Level 2 : FLOW (FLOW CONTROL) 
Both correspondents can initiate connection and regulate data traffic, 


but neither imposes error recovery. 

» Level 3 : RQST (RQST RECOVERY ) 
Both correspondents can initiate connection and regulate data traffic, 
but only partial error recovery is possible on demand to retransmit by 
the receiver. 


- Level 4 : FULL (FULL_RECOVERY) 
Both correspondents can initiate connection and regulate data traffic, 


and full error recovery is supported on demand to retransmit by either 
the sender or receiver, or both. 


physical link | single path | 
. |, ..,|&25 with error} multipath 
}point-to-point | 


| application type : | notification 


| transactional 


| file transfer/remote batch | 
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NETWORK LAYER 


The network layer provides the functional and procedural means for routing data 
between the transport pane of sender and receiver, across one EMEC eeee machine 


to the nexte ~ 


DATA LINK LAYER 


The data link layer manages and maintains data transmission between participating 
systems through HDLC lines of the communications network. ye 


Each HDLC line configured over TRANSPAC to the DPS 7 must be declared 
- at the one end on the side of the DPS 7, as a DTE (Data Terminal Equipment ) 


~. and, at the other end on the side of the switcher machine, in this canes oe 
PAC, as a DCE (Data Circuit-terminating Equipment). 

For a point-to-point HDLC line, it does not matter which side declares its end of 

the line as DTE or DCE. For as long as both ends are declared a DTE-DCE Rane the 

circuit, whatever the type of line, can be established. 

In GCOS, the declaration of its end of the HDLC line is specified in the TERMD 

parameter of the LN command for the TLT (Terminal end Line Table) of the URP 

firmware generation. 7 


PHYSICAL LINK LAYER 


The physical link layer is composed of all the hardware and its interfaces needed 
to support the network link. | | 


HOW DSA LAYERS ARE DISTRIBUTED 


The DPS 7 connects to the network 
- either through the Data Communications Controller of its own TDEGe rare’ URP 
e or through the DN7100 acting as its "front- end" processore 


DSA layers are spread differently according to the type of connection. 


DN7100 Connection : URP Connection : 


‘| Application 
Presentation | 


Session 


Application 


DPS 7 Presentation 


"pseudo-tra Ee 7 
= = Ghee ee DPS 7 Session 


exchange interface 


an 


In the URP connection, the DSA layers are distributed without overlap and corres- 
pond one-to-one with the DSA standard. | 


Transport 


Network 


DN7 100 


Data Link 


URP 


Physical Link 


In the DN7100 connection, however, additional "services" are present to ensure 
the "access'' between the systems, the DPS 7 and the DN7100, and the type of net- 
work configured to the DN7100, namely 

. the "pseudo-transport" in the DPS 7 

« the exchange interface present in both the DPS 7 and the DN7100 


. the Presentation/Session Layers of Message Management in the DN7100 in the case 
where a secondary network is configured. 
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Data 


Disassembly and Reconstitution 
across DSA Layers 


application layer 


user 
message 


resentation layer. 


ey, 


@ C018 EE Cee 


Y 


joe eec5e a @ Oversees 


oe 


|presentation | presentation| 


record 


5 3 i ia 
> session layer: i 
|}session]| . 


<ees 2 fee of > 
rn re 


‘layer 


id ° 
° e 


ear 

2 @ 
: e 
é e 
m4 ry 
® @ 
e e 
Py Py 
* 

° 
a 
Yr : 
e 
: e 
Ps e 
bs e 
e 
se 
e 
« 


eoecesea ds 


* @« 

2 * @ 

6 ® a 
e ° oe 


| | | ; | 7 : : A 
| | P| pbit streat| | ] | | 


1-08 


HANDLING DATA ACROSS THE DSA LAYERS 


In any data processing installation, there is no restriction on the quantity of 
data transmitted by either user or application. As far as both are concerned, 
they send or receive data in a continuous Stream 


As this data is moved across the DSA layers, it is broken down into units most 
conveniently and efficiently handled by the layer concerned. The sizes of these 
units are determined by the contraints imposed at the different layers, namely 


e internal contraints, being the buffers available that limit throughput and re- 
dundancy checks that increase overheads 7 : 


» and, external contraints, being the capacity of the public network that sets a 
ceiling on the speed and hence the volume of data to be carried. 


As data is passed down, the next lower layer breaks it down into its own units 

and tags on a header to each of the units. This header is then treated as part 

of the data in the subsequent lower layer which in turn performs its equivalent 
action. 


The header contains control information such as the type of information, Status 
of transmission, sequencing of units and addresses. 


At the lowest layer, data is transmitted as a bit stream across the network. On 
the other side of the network, this data is passed to the next higher layer 
which proceeds to assemble the bit stream into its constituent units. As data is 
passed up, the next higher layer strips the header off each of the units receiv- 
ed and reconstitutes the data into its own units. Each successive higher layer 
performs its own equivalent action. | | 


The net result of breaking down and reconstituting data is that what is received 
at the destination is a facsimile of that sent from the source Since it is pro- 
tected against error and loss. Each layer has its own specific protocol to go- 
vern the transfer of its data to the next successive layer. The information con- 
tained in the header is part of the protocol used as a control to ensure that 
the data is properly delivered in the same logical sequence as received whatever 
the direction of the transfer. 
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MAPPING OBJECTS OF THE PRIMARY NETWORK 


In GCOS, the Communications Network Configurator (CNC) utility is used to gener- 
ate the network. When CNC is executed, it builds up a set of network objects ac- 
cording to what has been declared. These objects reflect the network configura- 
tion and resources available to the user, and the intended use of the network. 


When the communications session is started up through ‘the ST network control com- 
mand, these objects provide the relational links to each other for the network to 
operate. 7 


The network objects under discussion here concern the primary network configured 
through the URP of the DPS 7 since all the objects relate to DSA layers and are 
visible to, and declarable by the user. | 


The diagram on the facing page shows an ensemble of such objects. 


While the primary network object is associated with a DSA layer, it cannot func- 
tion on its owns Instead, a group of objects interact together across DSA layers 
to provide the function associated with one given layer. 


An object can participate in more than one group. This overlap occurs when the 
object performs more than one role. Mapping network objects is a means of repre- 
senting their correlational groupings. 


In the text that appears on the following pages, objects are mapped not to the 
layer but to the function that the associated layer provides. 


"Mapping Transport Objects'' does not restrict mapping only the objects concerned 
with the transport layer. Instead, all the layers higher up from the transport 
layer are involved in the function of transport. Multiplexing protocol which is 
part of transport protocol is dealt with at the lower level "Mapping Network Ob-. 
jects” Since the wince! circuit must be established before UTEP CRT De takes 
place. . 3 


The network object takes the name of the CNC command only if it wholly bears a 
one-to-one correspondence with it, eege NR and CP. Although this is the case 
with LSYS and RSYS, LSC and RSC, and, LTS and RTS, group identifiers have been 
used for simplicity, namely, SYS, SC and TS. 


The designations "cp"! and "rts" are abbreviations for "communications path" and 
"remote transport Station"! as opposed to CP and RTS as CNC commands. 


The designations "Ins" and "rns"! denote that values must be substituted for these 
terms, that is, decimal values, as opposed to LNS and RNS as network objects. 


A network composed of point-to-point leased lines is a "native" network since no 
external constraints are imposed such as cumulative transit time and times of 
transmission. However, an X25 packet switching network, like TRANSPAC, being a 
public data network does impose such restrictions and therefore is a "foreign". 
network. 


Each time that the CNC description refers to an access to such a "foreign" net- 
work, the object FRGN is created to which all remote ae anes numbers (RNS) 


accesSing it, are attached. 


Mapping Objects 


of the 
Primary Network 


SYS Relationship of Objects 


——> simple, 1-to-1l 
| ——p multiple, 1-to-many 


List of Abbreviations and Mnemonics PLE — Plug 
GP Communications Path PRTG Protocol 

FRGN Foreign Network RNS Remote Network Subscription 
GAN General Access Network Table SG Session Control 

LCB Line Control Block SYS | System 

LNS Local Network Subscription TS Peanepoct Station 

NR Network Route VG Virtual Circuit 
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Mapping Session Objects 


The session is identified by its appropriate SC command at network generation by 
the following 


- a unique global external name (session name) which is 


- either specified as a positional parameter immediately after the name of the 
command 


- or implicitly taken from the name of the DPS 7 configuring the network, that 
is, the "local system" 


. and, a unique internal network address specified as the argument of the SCID 
(session control identifier) parameter. 


The relationship between session objects is 
- firstly, that there can be more than one session in a system 


» and secondly, that the session(s) is/are always serviced by at least one trans- 
port station 7 


The system, declared by its appropriate SYS command at network generation, has 
the notional concept of being a "container'’ into which objects, determining its 
function, are built. The system, as a network object, is "seen"! by other users of 
network through its session or specific session, where more than one is declared. 


Applications which represent the highest level of activities, can be regarded as 
the "contents" of the system. Applications are identifiable through their mail- 
boxes. Since applications are local to the system, the nemes of their mailboxes 
need not be unique throughout the network. The application, like the user, is i- 
dentified by its DSA address of the format <session-name>.< mailbox-name> which 
is unique throughout .the network. | | 


In the first stage of connecting the application to the user accessing it, the 
logical connection for both the correspondents must be established at their res- 
pective locations. This connection as implemented by session protocol is between 
the mailbox, on the one hand, and, on the other hand, the subchannel (SBC) which 
represents the functional interface to the respective transport station. 


logical connection {SBC [> lts/rts 


: logical connection 
transport station eas | ee 


terminal mailbox 


application mailbox 


Communications management involving the transport service is now required to pro- 
vide the access between the "local system" and other "remote systems". The trans- 
port station provides this access by handling all communications to and from the 
system For virtual circuits, transport protocol multiplexes logical connections 
over the same path to optimize the system's accessibility. 


In the case of the primary network being configured through the DN7100 function- 
ing as the "front-end system" of the DPS.7, the only mappable network objects are 
the system, the session and the "transport'. No other network object is visible 
since the DPS 7 is relieved of most of its DSA administrative functions by the 
DN7100. The "transport" defines the transport service and not the transport sta- 
tion. This "transport" is declared in the FNP command at network generation and 
maps the DN7100 over the PSI of the DPS 7. 
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Mapping 


Session Objects 


SEESEES Relationship of Objects 


——{> simple, 1-to-1 
——p multiple, 1-to-many 
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The objects in the session layer are generated by the following CNC commands 
» SYS - LSYS or RSYS 
»« SC - LSC or RSG 
» TS - LTS or RTS. 
The relationship between the objects is as follows, 
- there may be several SC processes in a single SYS _ 


» while SC processes are always serviced by a single TS, the SC itself may be 
serviced by several TSs. | | 
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Mapping Transport Objects 


The transport station is "concatenated" to its associated session through its 
name being specified as the argument of the TS parameter in the preceding SC com- 
mand. If more than one transport station is to serve a given "remote session", 
the list of rts's must appear in the TS parameter of the relevant RSC command, © 
followed by as many RTS commands. However, the LTS command, like the LSYS and LSC 


commands, is unique in the CNC description. 
| 


Since the transport station is strictly local to its own session, its name need 
not be network-wide. 


In the connection between the lts and rts, both transport stations can be consi- 
dered the physical ends of a conduit, the conduit itself being provided for by 
one or a number of network routes. Each of these network routes is defined for a 
given rts and represents a localized image of the physical path available to the 
lts to "exit" to the rts. 


The conduit, so far established, assures the connection between the transport 
Stations. This connection as implemented by transport protocol is between plugs, 
each plug representing a table for updating the dynamic context of its being 
matched one-for-one with its correspondent. 


In the second stage of connecting the application to the user accessing it, the 
plugs of the transport connection link up with the subchannels of their respec- 


tive logical connections. 
i : terminal este 


logical cxn SBC] 
For a point-to-point line, the connection between the application and the uSer is 


= mailbox | 
~e———- transport protocol ——»: 
complete since there is direct multiplexing between the logical connection and 


{$< $$ $n SESSION protocol 
the transport connection. 


At the time of connection, the two transport stations negotiate the number of 
fragments (window) and the size of the fragment for their flow control. The win- 
dow defines the number of fragments that the sender station can transmit before 
waiting for an acknowledgement from the receiver. 


A switched public data network, such as an X25 packet switching network or an 
X21 circuit switching network, is considered an foreign network (FRGN). 


In the case where such a network is used, the following relationships are invol- 
ved 


.» the rts is accessed through a list of remote subscription numbers (RNS) to est- 
ablish the virtual circuit 


e all the RNSs declared are mapped on to the FRGN 


. and, the administrators of both the "local system" and the ''foreign network" 
must agree on a common local subscription number (LNS) to access the "remote 
system' through the FRGN. 


The LNS is used for connection by the network protocol. 
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The objects in the transport layer include those in the session layer and are 
generated by the following CNC commands or their internal parameters 

» SYS (LSYS or RSYS) 

5 SG (LSC or RSG) 

a" ES (LTS or RTS) 


-~ NR (NR) 
- RNS | ADD 
. FRGN PERT? 


- PLG (XCNT ong or MUXPRM, oiyp)* 


All call numbers related to the "foreign network" are chained to its FRGN. 
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Mapping Network Objects 

The network layer is optional. However, when it is present, it provides the means 
to switch the packet through a network route. 

The types of network routes, as shown on the facing page, are 

1) Two network routes are each mapped over different point-to-point HDLC lines. 


This is an example of two "remote systems" that can be connected to each other 
through a number of network routes. 


2, 3 and 4 are examples of several network routes sharing the same communications 
path. | 


2) System A connects to system B over 1 network route while B can connect to A 
over either of its 2 network routes. 


3) 2 network routes from system B are mapped over 2 different virtual circuits, 
both of which share the same HDLC line over the packet switching network to 
access system A. 


4) Network routes from system A are mapped to systems B and C over a Single point- 
to-point HDLC line. 


The network service involved in an exchange with an rts, can be regarded as having 
two functions 


° firstly, addressing the system for the purpose of routing an access to it 


- and secondly, selecting the network route for the purpose of conveying the pack- 
ete | 


DSA provides for two routing techniques dependent on the type of packet, namely 


. the datagram which, being a discrete packet, is an independent entity from other 
packets and must contain within itself all the service information concerning 
routing and controlling its transfer 


e and, the non-datagram which, being a linked packet, is one in a sequence of pac- 
kets for which only the first packet contains complete service information con- 
cerning the routing and controlling the transfer of the entire packet sequence. 


Datagrams can be transmitted over as many different network routes as are avail- 
able even if the datagram is logically either the result of a preceding datagram 
or the prompt to a Succeeding datagram. 


Non-datagram data is transmitted over a network route fixed for the duration of 
the entire transmission, the intermediate switcher machine having no choice of 
selection once the network route is established. 


The network route can be mapped over 
« either a point-to-point HDLC line 


» or a virtual circuit if the communications path accesses a packet switching net- 
work, like TRANSPAC. 


Transport connections can be multiplexed over the virtual circuit. Multiplexing 
protocol is part of transport protocol to establish the transport connection each 
time that the session requests it. Multiplexing allows several transport connec- 
tions over the same virtual circuit. | 


The network protocol sets up the virtual circuit and, where multiplexing occurs, 
clears down the virtual circuit when the last transport connection has terminated. 
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data link layer | 


netroute 


o> Serrneern 
Ort Naren 


physical layer | | physical layer 


In the third and final stage of connecting the application to the user accessing 
it, transport connections between several correspondents can be multiplexed over 


7 - virtual circuit. 
= os ei 


et 
coe aecetmoecanee 


m—enetwork protocol 


m= DSA transport protocol ——————} 


DSA session protocol 


The network route-is "concatenated" to its associated rts through its name being 
specified as the ergument of the NR parameter in the preceding RTS command. If 
more than one network route is to serve a given rts, the list of nr's must appear 
in the NR parameter of the relevant RTS command, followed by as many NR commands. 


The NR is always mapped over a communications path. If the CP is an access to an 
X25 packet switching network, like TRANSPAC, then the NR is always associated 
with a virtual circuit. 


To establish the VC, there must be | 
- a local subscription number CLNS ) For the "local system" to "enter"! the network 


- and, a remote subscription number aN) to "exit" feoneeie network to access 
the "remote system". 


Both LNS and RNS are decimal numbers. 


The Ins must be specified as the argument of the SUBNB parameter of the LSUB com- 
mand. The name referencing the Ins must. be 


° declared in the LSUB command 
» and, specified as the argument of the SUBSCRID parameter in the CP command. 


The rns is specified as the argument of the ADDR parameter in the preceding RTS 
command. If more than one rns is to serve a given rts, the list of rns's must ap- 
pear in the ADDR parameter of the relevant RTS command. Since TRANSPAC is a for- 
eign network (FRGN), all rns's are mapped on to ite 


~~ 


Transport protocol parameters, like the options described on page 1-05, are asso- 
ciated with the network route and are stored in a table (PRTC). The PRTC is built 
from parameters specified in the XPRTC command. These parametric values are used 
to negotiate a connection with the appropriate rts. 
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Mapping Data Link Objects 
Data link protocol governs the physical exchanges over link paths. The link paths 
are eStablished for . 


« virtual circuits of the switched public data network, like TRANSPAC, which sup- 
port , 


- the primary network interconnecting systems 


- and, the secondary network involving the system, on one anes operas its 
ecentnals across such a network, on the other side : 


e and, point-to-point leased lines joining up systems in a primary network. 


The term Npoint- -to-point" in the context of the leased line refers to the aie 
access’ between a system at one point and another system at the other point. _ | 


The protocol used for the link bath is ‘point- -to- -point HDLC (High- lével Data- Link. 
Control). The term "point- -to-point" in the context of HDLG is as opposed to. “mu 1- 
tipoint" for which polling is available. : 


The packet is placed into frames for retransmission by HDLC as a bit stream along 

the physical link. 

The communications path is "concatenated" to its associated network route through 

its name being specified as the argument of the CP parameter in the Prceaes he NR 

command. | 

The cp which is the principal data link object is related to the nr according to 

the link path over which the nr is mapped, namely 

- if a virtual circuit of the same loéal subscription number (LNS), several nr's 
can share the same cp 


» or, if a point-to- point leased line, there can be only one cp to the nre 
The point-to-point leased line is specified as the argument of ene AGCESS parame" 
ter of the CP command. : 


“Objects defining the data link itself are the general access network table (oa) 
and the line control block (LCB). Both these objects are created each time an __ 
HDLC line appears in the CNC description — 

The GAN heads the output physical queue(s) and de westeiaved with at least one 
cp. Several cp's can uSe the same GAN. The GAN determines which data stacked in 
the queue(s) is to be despatched to what destinations. 


The LCB is used by one or several GANs and controls the data transfer along the 
physical link. | - 
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Mapping 


Data Link Objects 


SYS Relationship of Objects 
——> simple, i-to-1 
| ——p multiple, 1-to-many 


The objects in the data link layer are either generated by, or the result of, the 
following CNC commands 
- NR (NR) 


« CP (CP) 
- GAN (LINE, 310? 1 gan per hdlc line 


- LCB (LINE, gic)? 1 lcb per hdlc line. 
The CP object is the common relational object whether the link is either "mono" 


or "multi'. 
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MAPPING DSA ELEMENTS ON GCOS COMMUNICATIONS COMPONENTS 


These DSA elements are those other than objects of the primary network and which 
can either be mapped on to physical elements of the network or be associated with 
conceptual functions known to GCOS. 


Whereas mailboxes and workstations are piyeiedl elements, the logical connection 
and the session are not. - 


The diagram on the facing page shows a schematic relationship of the elements. The 
term "correspondent"! refers to both the application and the terminal, representing 
the user. The term "transport connection'' refers to the communication with a.re- 
mote mailbox in which the correspondent is 


- either a terminal in the secondary network accessed over a primary network such 
as TRANSPAC 


- Or an application in a remote system accessed over the primary network. 


In the case of the URP connection, the DPS 7 assures the transport, whereas in the 
case of the DN7100 connection, it is the DN7100, not the DPS 7, which assures the 
transport. pee page 1-Q7. : , 


In a typical DPS 7 installation, the most likely communications services in use 
are : 


e IOF whose monitor.handles user connections to interactive applications 
- TDS whose executive Supervises simultaneous transactional processes 


» MCS, composed of QMON and MAM, which provides the control interface for user 
communications applications 


“2 and, NASF whose file server provides data support. for ADM when servicing the 
DN7100. 


The logical connection between NASF and ADM is established through their respect- 
ive mailboxes. This connection is a mono-logical connection and, for simplicity, 
is shown with the same symbol as the "terminal mailbox". 
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Mailboxes 
A mailbox is the addressable point-of-entry providing access to correspondents of 
the network. 


Within the same system, the name of the mailbox need only be unique at session le- 
vel. However, throughout the network, in order for mailboxes of different systems 
to be unique, they must be addressed in the format <session-name>.<mailbox-name>. 


TERMINAL MAILBOX 


Terminal mailboxes known to GCOS and managed by GCOS, apply to terminals in the 
URP local network and the TRANSPAC/URP secondary network. 7 


There is one mailbox per terminal which is identified by the same name as declared 
in the appropriate CNC command at network generation 


» TERMNL command for a terminal in the URP local network 
- and, RDTN command for a terminal in the TRANSPAC/URP secondary nieuuele 


The RDTN command is preceded by an RDTE command which describes the type cf equip- 
ment and the mode of management of the virtual circuit between the correspondents. 


APPLICATION MAILBOX 


Application mailboxes provide access to GCOS communications services, see pages 
2-06 through 2-08. 


Unlike the terminal mailbox, the ey Penceunen mailbox handles several correspond- 
ents, see "Logical Connection". 


All communications services handle one mailbox each for all users connected to it, 
specific cases being the following 


- TDS : Each version of TDS handles up to 2 mailboxes, the second meilbox being 
optional for the master terminal 


- MCS : For each MCS application, every queue declared corresponds to one mailbox 
and is handled by QMON 


- TILS : The number of mailboxes depends on the communications session to be simu- 
lated | | 


- for an IOF session, only one mailbox need be declared | 


- for a TDS session, more than one mailbox can be declared, up to a useful maxi- 
mum of "spawned" terminals. 


The naming of application mailboxes is as follows 

. IOF and RBFO/FTF6 take the same mailbox names, IOF and RBF, respectively 

» DJP/DFT and CARDLESS are known to GCOS as FILTRAN and READER, respectively 
» OLTD takes the name TD 


» MCS application mailboxes take their names from their corresponding QUEUE com- 
mands declared at CNC generation 


. NASF uses two mailboxes, namely 
- the $LOGFILE mailbox for receiving AEP records from NADs of other DSA systems 
- and, the $NASF mailbox for exchanging files between administrative correspon- 
dentS. | 


- TDS : for each version, up to 2 mailboxes can be declared in the TDS SECTION of 
the TDS generation program 


- the mandatory user mailbox takes the name defined as the argument of PROGRAM-ID 


- and, the optional master terminal mailbox is defined as the predicate of the 
clause MASTER MAILBOX IS <master-name> 


. TILS defines its mailboxes in its declaration file 
- the mandatory user mailbox is declared in NAME, the default being TILS 


- and, all other optional mailboxes are defined in as many PATHs. 


ADMINISTRATIVE MAILBOX 

Administrative mailboxes provide access to communications management components. 
These mailboxes are intended for use by the system for administration and control. 
The names of the administrative mailboxes for ADM, NASF and DSAC, are * 
« ADM MBX for ADM (this mailbox is ipeenats 

« $NASF for the ASF function of NASF 

« $LOGFILE for the AF DSALOG function of DSAC (ASF log function) 
e and, $NAD for the AF LNAD function of DSAC. 


Workstations 

A workstation represents a service or a collection of mailboxes. Unlike the mail- 
box, the workstation is not a directly addressable entity. 

The name of the workstation is used in communications service commands 

» to make available the corresponding service to other system components 

- and, to modify the parameters of the mailboxes pertaining to it. 


Communications services, by their distributed nature, function both as application 
mailboxes as well as service workstations. These are therefore treated here al- 
though these services are not communications management components. 


BINS WORKSTATION | 

The BINS workstation takes its name from the GENCOM command at CNC generation. 
Its name is used | | 

- optionally, to start BTNS 


- and, to provide the userid of terminals declared with the AUTO option, of the 
format <gencom-name><terminal-name> or See name ><terminal-name>. 


The "terminal manager" corresponds to the set of terminal-mailboxes and is mapped 
on to the BINS workstation. 


The main administrative functions of the BTNS workstation that are available to 
the user, are executed through the following network control commands 


- RT and HT : fer modifying the number of active terminal-mailboxes 
- MTL, MTP and MIT : for modifying the operability of the line and terminal 
( — 


- and, TT : for shutdown. 


The functions of BTNS are described on page 2210, 


TNS WORKSTATION 


The TNS workstation functions with the BTNS service. It is an internal transport 
workstation known to GCOS as DSA TS. 


It groups application-mailboxes of the system within the primary network. 
The TNS workstation is activated when 

- BINS is started up | 

- and, the first HDLC line is activated. 


TNS is deactivated when the last HDLC line is deactivated. For the communications 
session, TNS terminates when BTNS shuts down. 


The only adntarstearive functions of the TNS workstation that are Systane to the 
user, are executed through the RT and HT network control commands 


. for tuning, by starting up the "injector" facility for simulating the session 
layer between 2 transport stations, and for generating data traffic 


- and, for maintenance, by providing a complementary trace for the TNS domains and 
their essociated subdomains. 


The functions of TNS are described on pages 2-10 and 2-11. 
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FNPS WORKSTATION 


The FNPS workstation defines the "transport"! over the FNPS/DN7100 interface. This 
"transport"! or FNPS workstation takes its name from the FNP command, declared at 
CNC generation, which 


- describes the operation of the FNPS service 
- and, maps the DN7100 "front-end" system over the PSI of the DPS 7 "host" 


Up to 6 FNPS workstations can be configured on a DPS 7 installation, each of which 


corresponds to a separate occurrence of the FNPS service for the associated DN7100, 


however, only 4 FNPS workstations can be simultaneously active. 


Whereas the name of the FNPS workstation is used to identify the appropriate FNPS 
service to be started up or shut down, the name of the DN7100 "session-control" is 
used to "enable" or "lock" the appropriate PSI of a bi-PSI DN7100. 


The only administrative functions of the FNPS workstation that are available to 
the user, are executed through the following network control commands 


» MIF : - for tuning, by stopping and starting up the "watchdog" status exchanges 
between the workstation and the DN7100 


- and, for maintenance, by providing the trace over the FNPS/DN7100 inter- 
face 


- and, TT : for shutdown. 


The functions of FNPS are described on page 2-11. 


SERVICE WORKSTATION 


The service workstation corresponds to the application mailbox or a set of appli- 
cation mailboxes associated with the communications service. Service workstations 
derive their names from.their corresponding application-mailboxes. 


For IOF, RBF6/FIF6 and DJP/DFT, the names of, and the external administrative 
functions for, these workstations are not visible to the user because these ser- 
vices are automatically started up when either BINS, TNS or FNPS are started up. 


TDS, MCS applications, TILS and OLTD must be started up as job steps after either 
BINS or FNPS have been started upe In the JCL subfiles for starting these services, 
the JOB statement can take any user-defined name, whereas the STEP statement must 
bear the following respective names of the load-module 


- TDS : STEP <tds-name>, where tds-name is the argument of PROGRAM-ID of the TDS 
SECTION of the generation program 

» MCS : STEP <load-module-name>, where smenane identifies either a monprocess or 
multiprocess load-module 7 

. and, TILS : STEP H TILS, indicating that the TILS service is required to be run. 


The JCL subfile for OLTD is internal to GCOS and the names of the 2 consecutive 
steps, H TD1 and H TD2, are not visible to the user. The name of the OLTD service 
is known to GCOS as TD, and a test is launched by an "SJ TD <parameters>" opera- 
tor command. 
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TDS Workstation 


The TDS workstation comprises two app Lication-mailboxes. The workstation is acti- 
vated when the associated TDS job step is started. 


If a master terminal has been declared, commands addressable to the TDS workstation 
concerning its startup and shutdown, M START and M STOP respectively, can now be 
entered at the designated terminal and executed. In the absence of the master ter- 
minal, these commands are entered at the system console. 


QMON Workstation 


The QMON workstation is a group-set of all ep PE aUhonmarsoeree corresponding one- 
for-one with their respective MCS queues. 


The term "MCS queue" refers to the queue used by the MCS a to serve one 
of the following functions 


- a BINS terminal-~-queue to serve a bemninal in either the URP local network or the 
TRANSPAC/URP secondary network 


- a DSA-queue, see ''Session" 
° OF, a program-queue for MCS applications to receive messages. 


The QMON workstation is known to GCOS as QMON and is activated after either BINS or 
FNPS have been started up by the "ST QMON!'' network control command. ve as a ser- 
vice has a mailbox known to GCOS as QMONMBX. 


QMONMBX is involved in the logical connection with the terminal-mailbox under the 
following conditions 


e at connection time if the associated terminal- -queue is "enabled'' and contains da- 
ta to be output to 
- either an "automatic'' terminal 
- or a terminal for which neither an application has been specified nor a default 
application exists for the project 


« when a terminal A, say, logs on to the terminal-queue of another terminal B, Say, 
which is already "logged", so that messages entered at A are transmitted to B 


e and, for a connection between an application and a terminal, if no $QASSIGN IN 
has been declared for the program-queue. 


For further details, see "Connection Handling", MCS User Guide. 


The external administrative functions of MCS are not visible to the user under the 
following conditions 


. if the logical connection does not involve the terminal-mailbox, in which case 
QMON is not required 


. and, if the MCS application is declared "automatic", in which case operator in- 
tervention is not required. 


The facility for declaring an MCS application "automatic" is indicated at network 
generation by both of the following CNC options | | 


» the INIT parameter of the QUEUE command specifying the name of the application 


» and, the APPLIB parameter of the GENQMON command specifying the cataloged Jibre- 
ry of application JCL subfiles, of which the referenced application is a member. 


Logical Connection 


The logical connection is the means whereby a messSage-path is set up between two 
correspondents. The terminal mailbox handles one correspondent and is a mono-log- 
ical connection, whereas the application mailbox handles several correspondents 
end is a multi-logical connection. 


At connection time, tables representing the correspondents and their management 
parameters are accessed by VCAM. If the connection request is Successful, VCAM 
dynamically generates parametric values for these tables, namely 


» to number the logical connection tu match the internal VCAM logical connection 
table in order to establish the corresponding parameters to be negotiated for 
the connection 


- and, to return to the application, the session control identifier to be used for 
all exchanges over the connection. 


session 

The session is associated with a Server. The session server is the automaton in 
the session layer which implements session protocol. 

The session is addressable in the DSA network through 

» its session name which is a unique global external name and is alphanumeric 


- and, its session control identifier which is a unique internal network address 
composed of two decimal integers, 


Refer to "Mapping Session Objects", pages 1-12 and 1-13. 


The session layer resides in all DSA systems, "local", "front-end" and "'remote''. 
In order to locate a mailbox in any of the systems other than the local system, 
the DSA address of the format <session-name>.<mailbox-name> is used to identify 
the QUEUE command at network generation, so that identification is unique. 


Such a mailbox identifies a DSA-queue which, when used to send messages, can be 
« either a terminal connected to a "front-end'' or "remote''! DN7100 


- or an MCS application in a "remote"! DPS 7. 
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SECTION ITI 


GCOS SUPPORT OF NETWORKS 


Communications Supported by the DPS 7 depends on 


- the hardware connected to its PSI (periperal subsystem interface), being either 
the integrated URP of the DPS 7 or the DN7100 "front-ending"' the DPS 7 


- and, the physical link established over either the URP or the DN7100 
- between the DPS 7 and another "'remote system" in a primary network 
- and, between the DPS 7 and its terminals in a Secondary network. 


From now on, TRANSPAC will be referred to as the example of an X25 packet switch- 
ing network. 


Primary networks can be established over TRANSPAC switched virtual circuits or 
connected over point-to-point leased lines. 


Secondary networks comprise terminals connected to the DPS 7 in 


- local networks, whereby terminals are accessed directly, that is, through point- 
to-point leased lines or over lines of the telephone and telex networks 


.» and, TRANSPAC secondary networks whereby terminals are accessed over switched 
virtual circuits. 
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TYPES OF NETWORKS 


The types of networks schematically shown on the facing page are 


- the primary network, composed of the systems A, B ('"'front-ended' by E), C and D, 
connected as follows 


- A connects to C directly through its URP over a point-to-point line and a 
TRANSPACG switched virtual circuit 


- whereas, B connects to A and D through the intermediary of E, its front-end 
system, 


e over TRANSPAC switched virtual circuits 
- and, in the case of B and D, also over a point-to-point line. 


» and, secondary networks, involving the groups of terminals, AL and AS, and, EL 
and ES, connected to their respective "local systems" as follows : 


- AL and AS connect to A directly through its URP, A being therefore their "loc- 
al system'', to form the URP local network and the TRANSPAC/URP secondary net- 
work, respectively 


- and, EL and ES connect directly to E but only indirectly to B, E being there- 
fore their "local system'' and not B, to form the DN7100 local network and the 
TRANSPAC/DN7100 secondary network, respectively. | 

In the examples of A and B, as DPS 7 "local systems" | | 
» A, through its URP, is configured to both the primary and secondary networks 


. while, B, by being ''front-ended" by E, is only configured to the primary network 
but not to secondary networks; instead the secondary networks shown are config- 
ured to its "front-end system'' E and the terminals have indirect access to B. 
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COMMUNICATIONS COMPONENTS 


GCOS communications software is structured around three principal DSA layers to 
provide the support of the different types of networks described, as follows 


- the application layer occupied by the communications services being 


RBF6/FIF6, Remote Batch Facility/File Transfer Facility from/to the Mini 6 
DJP/DRB, Distributed Job Processing/DSA File Transfer facility between DPS 7s 
IOF including the "pass-through" function operating under IOF 

TDS, Transaction Driven Subsystem 

CARDLESS, also known to GCOS as READER, for DPS 7 installations using diskette 
TILS, Transactional and Interactive Load Simulator 

OLTD, On-Line Tests and Diagnostics | 

MCS, Message Control System composed of MAM and QMON 

NASF, for DN7100 service functions and DSA logging 


. the session layer occupied by VCAM which provides the message management by 


handling connection and dialog functions 


and, allowing direct access to terminals and applications without their being 
aware of the communications path or mechanism for establishing their connect- 
ion 


e the transport layer occupied by the following modules for providing the communi- 
tions management according to the PSI connection, namely 


for the URP - 
- BINS for managing terminals in the URP local network 
» and, TNS, a function of BTNS/HDLC 
- for enabling the DPS 7 to connect directly to the primary network 


- and, for managing terminals in the TRANSPAG/URP secondary network 


- for the DN7100 


» FNPS for enabling the DPS 7 to interface at transport level with the DN7100 
thereby allowing the DPS 7 to connect "indirectly" to the primary network 


Note : Terminal management in the DN7100 local network and the TRANSPAC/ 
DN7100 secondary network is a function internal to DNS software and 
is not visible to GCOS. Terminals connected in both these networks 
are not declared in the GNC description of the DPS 7 "local system". 


However, "remote systems'' connected to the DPS 7 via the DN7100 must 
be declared together with their associated FNPS services in the CNC 
description 
» ADM/NASF (ADM file server) for executing service functions on a given 
DN7100 and is therefore mutually exclusive to the occurrence of its associ- 
ated FNPS service. 


GCOS support for networks concerns primarily the network management component of 
communications software, being VCAM operating in conjunction with any of BINS, 
TNS and FNPS. Se : : 
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Communications Services 


Communications services are applications which are 
- either "packaged" products supplied by BULL Systémes such as IOF 


e or communications software which are needed by user-defined applications to in- 
terface with VCAM such as TDS and MCS. 


RBF6/FTF6 
RBF6 and FIF6 are two services in the DPS 7 that enable it to link up with the 
Mini 6. Homologous services in the Mini 6 are N _RBF7 and N_FTF?. 


The term RBF refers to the functions provided by RBF6 in the DPS 7 and: N_RBF7 in 
the Mini 6, and allows the Mini 6 Station cperator 


» to submit a "'remote" job to the DPS 7 for execution 
» and, to receive the JOR and SYSOUT listings of the job submitted. 


The term FIF refers to the functions provided by FTF6 in the DPS 7 and N FTF7 in 
the Mini 6, and allows the transfer of files in both directions. Both the Mini 6 
Station operator and the DPS 7 system operator can 


» transfer files in either direction of the recipient systems 


e and, control and monitor this transfer. 


DIP/ DFT 


DJP and DFT are two services that enable the DPS 7 to link up with another DPS 7. 


Both these services are available to any IOF user logged on to the participating 
DPS 7. Job submission (DJP) and file transfer (DFT) are symmetrical between the 
two DPS 7s since these activities can occur in either direction. 


The file containing the job to be submitted need not necessarily be in the same 
location as the machine executing the job. The keywords SITE and HOST are used to 
indicate the location of the file and the location of the executing machine, res- 
pectively. | 


The transfer of file contents is requested at either DPS 7. During the transfer, 
the operation can be controlled and monitored at both the DPS 7s. 


TOF 


IOF is an interactive service which provides the user with such tools as 


» creating, updating and deleting source files or subfiles containing data, lang- 
uage instructions, processor commands or GCL statements 


. launching and controlling batch jobs, MCS applications or other communications 
services such as TDS, from any general-purpose terminal 


» scanning and receiving output reports from jobs submitted 


» and, executing interactively any application, utility or processor. 
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TDS 
TDS is an executive for initiating, scheduling and monitoring transactions execut- 
able in the form of transaction processing routines (TPR). 


The executive is parametrized at TDS generation to the requirements of the user, 
while the TPRs which are user-defined, are written in COBOL and RPG. 


A generated version of TDS with its associated TPRs is started as a job step 


» providing the interface for connections and disconnections, and data exchanges 
between the TPRs and VCAM 


» dispatching messages across TPRs according to the contents and context of the 
message, for example, the arrival of a message for a TPR which is not the first 
TPR of the transaction | 


e maintaining "'before'' and "after" journals for data security 
e protecting updates and movements of data in the IDS "data base" through GAC 


. and, restarting after an abort or system crash, 


DSAC 


DSAC provides the services which enable the DPS 7 to administrate and control its 
networking environmente 


It allows the exchange of control information between participants of the network, 
and, the journalization of events occurring throughout the network. 


Detailed information on DSAC is treated in Section Ve 


TILS 


TILS simulates a 'workload" for IOF and TDS executing on either the same system 
or another system connected over the DSA network. 


Since interactive and transactional applications have dynamic resource require- 
ments, TILS enables the DPS 7 user to gauge the effect of such demands on the per- 
formance of the system before extending the work capacity of either or both appli- 
cations. 


The results obtained from TILS must be interpreted with the results obtained from 
the System Behavior Reporter (SBR) which gives the overall performance of the DPS 
7 as it currently stands. 


OLTD 


OLTD is a "maintenance" service providing .a set of verification, confidence and 
diagnostic tests that can be called interactively by users of the DPS 7. 


The purpose of executing these tests is to provide preliminary symptoms at differ- 
ent levels of any suspected anomaly in the system These symptoms can then be 
transmitted to the Service Center for an initial assessment of the most likely 
cause and best remedy of the anomaly before the engineer arrives. 


The advantage is therefore to minimize the time taken to locate the anomaly and to 
reduce the "down" time of the affected component. 
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MCS 
MCS provides access to user-defined queues. Its functions are provided by MAM 
(Message Access Method) and QMON (Queue Monitor). 


MAM is a set of queue control procedures contained in the H _SM2 member of the 
sharable module library. QMON is a separate load module which interfaces VCAM ses- 
sion control procedures with MAM queue control procedures. , 


MCS applications use queues to input and output data. These applications are writ- 
ten in MCS COBOL and GPL. 


MCS applications can be executed once QMON: is started up aS a job step. 
The functions provided by MCS are 

‘ managing queues of messages in memory and on disk files 

» recovering disk queves after an 


» synchronizing and maintaining communication between MCS applications within the 
same DPS 7 system | : 


e initializing and formatting disk queue files. | 


NASF 


NASF has two functions, namely 


e as the file server to ADM, it provides service functions on the DN7100, see page 
2-11 | | | | 

. and, as ASF proper, it is automatically enabled as soon as a primary link is 
established in the network, independently of the connection type, that is, éi- 
ther through the URP or the DN7100, thereby allowing the DPS 7 to receive incom- 
ing administrative sessions from correspondents of the primary network on the 
$NASF mailbox. 


* as ADM file server, NASF 


e either retrieves data from its files to input to ADM for generating DNS software 
and, subsequently for loading the DN7100 


» or stores the memory image of the DN7100 when a dump is required. 


USER DEFINED APPLICATIONS 


User-defined applications are either transaction processing routines (TPRs) or 
MCS applications. 


TPRs, written in COBOL and RPG, are compiled and linked separately. On execution 
of a TDS generation, the TPRs specified are dynamically linked to the TDS execu- 
tive into private sharable modules. The advantage of this dynamic linking is that 
when a TPR is modified, the TDS load module need not be regenerated. 


MCS applications, written in MCS COBOL and GPL, are either monoprocess or multi- 
process load modules. They communicate with terminals, and other remote or local 
MCS applications, through queues specified by the user and managed by MCS. 


Message Management 


VCAM is a set of session control procedures eoneence in the H _SM1 and H_SM2 mem- 
bers of the sharable module library. 


It provides GCOS communications services a unique "direct access' common interface 
to users and applications throughout the network. 


The functions provided by VCAM are 
- handling the DSA connection and session protocols 
- centralized management of security checks related to the connection protocol 


» centralized management of dynamic DSA entities Such as workstations, Systems, 
mailboxes, logical connections and message-groups within GCOS 


. and, providing the internal means of communication between a communications ser- 
vice such as TDS, and a batch entry program, in the same DPS 7. 
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Communications Management 


Whereas VCAM provides a common message management interface for all. sessions, com- 
munications management is composed of three separate modules according to the type 
of network and the hardware connected over the PSI of a BES Te 


These modules are 
- BINS for the URP local net work 


- TNS, a function of BINS/HDLC, for the mpaNSERC TURE secondary network and the 
primary network 


Both BINS and TNS function through the integrated URP of the DPS a 


» and, FNPS for the TRANSPAG/ DN7 100 secondary network and the primary network ac- 
cessed through the DN7100 functioning as the "front-end'' system for the DPS 7. 


BINS 
BINS handles terminals connected over switched and leased lines of the URP local 
network. It is started up as a job step by the ST system console command. 


The functions of BTNS are implemented by SNC (Secondary Network Controller) and LM 
(Line Monitor). | 


BINS performs the following functions 


- initializes URP communications firmware 


polls multidrop lines and manages terminals 

- handles data exchanges and recovers errors in transmission 
» manages buffer pools 

- analyzes and executes network control commands 


» manages the local dialog and handles the connection protocol from the side of 
the terminal mailbox 


- and, keeps track of network events for compiling statistics and providing the 
line trace. : 


TNS 


The functions of the Transport and Network Subsystem are implemented by a network 
process and an administrative process. The network process is the major of the two 
processes and occupies a higher priority. 


The network process is shared with the BINS "terminal manager’. The term "terminal 
manager"! refers to a particular function of BINS which 


» provides the dialog conversion between the terminal and the application 


» and, allows the DPS 7 to access terminals of the secondary network over the pri- 
mary network such as TRANSPAC. 


The administrative process is the interface for the asynchronous processing of op- 
erations between the network and session layers. 


TNS is started up at the same time as BTNS. 
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TNS performs the following functions 

- synchronizes the DPS 7 with the TRANSPAC switcher 

- sets up the virtual circuit, and transmits and controls X25 packets 

- establishes the transport connection, and transmits and controls fragments 
- and, handles connection requests as follows 


- for terminals, connection to the session is routed through the "terminal mana- 
ger" 


- for applications, connection to the session is routed directly. 


FNPS 


When service functions are being performed on a DN7100, its associated FNPS ser- 
vice cannot be started at the same time. 


FNPS functions with DNS, the DN7100 system software. At CNC generation, the DN7100 
which is to function as the "front-end" system of the DPS 7 "local" system, is de- 
clared in the FSYS command, while the associated FNPS service which is to function 
with the DN7100 in question, is declared in the FNP command. 


At run-time, the MIF network control command addressed to the "fsys-name" and spe- 
cifying AUTO 


- loads the DNS system software in the DN7100 | 
- and, subsequently starts up the associated FNPS service. 


If AUTO was not specified in the MIF command, the associated FNPS service must be 


FNPS performs the following functions 
_« initializes and manages buffer pools for the interface with VCAM and PIO 


e provides a "pseudo-transport" by relaying the transport connection established 
by the DN7100 to the session layer in the DPS 7 


» and, manages the allocation of logical channels between 'native'' and SIRIS modes. 


ADM 


ADM functions with the NASF file server to perform service functions on the 
DN7100, see page 2-08. 


These service functions are executed through the MIF network control command ad- 
dressed to the "fsys-name" identifying the DN7100. The operand specified in the 
MIF command determines the required function as follows 


» SYSGEN : for generating DNS system software necessary for the needs of the DPS 7 
host : : 


. AUTO : for loading the DNS system software previously generated through SYSGEN 
and, for subsequently starting up the associated FNPS service 


- and, DUMP : for dumping the memory image of the DNS system software. 


According to the "load" option specified at CNC generation in the FNP command, the 
DN7100 can be loaded either remotely by the DPS 7 host.or locally from its own 
diskette. 2 
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COMMUNICATIONS NETWORK CONFIGURATOR 


In DSA, there is no global network configuration but a configuration of each sys- 
tem with respect to other systems. Each system, in its turn, describes its corres- 
pondent systems as it sees them, until all the correspondents, having declared 
their own network configuration, can mutually identify each othere Unique address- 
ing of each system allows systems throughout the network to communicate. 


A system is a set of hardware and software resources. In terms of configuring its 

network, the system represents a "'container'' into which objects, which determine 

the function of the system as a participant of the network, are built. The system 
configures its own specific network in terms of a 


e its own communications software 
» the terminals under its control 
» the systems with which it wants to communicate 


» and, the types of networks that provide the links to its terminals (secondary 
networks) and its correspondent systems (primary networks). 


CNC is a GCOS utility which allows the DPS 7 installation to define its network 
configuration with specific sets of commands applicable to the resources required 
for 


» the URP local network (BINS) 

» the TNS primary network (connection of the DPS 7 over its integrated URP) 

» the FNPS primary network (connection of the DPS 7 over the "front-end"! DN7100) 
e and, the TRANSPAC network which provides the links to 


- its terminals connected over it (TRANSPAC/URP secondary network requiring BINS 
and TNS support) | 


- and, systems of the primary networks, as opposed to point-to-point lines. 


The input to CNC are its commands and the configuration of the DPS 7 as defined in 
the System Resource and Status Table. The SRST is the description of all the hard- 
ware and their associated firmware at the DPS 7 "site" as built by the CONFIG uti- 
lity at installation time. | 


The output from CNC is a set of communications system tables being 


BINS tables for managing the part of the network accessed over the URP, contain- 
ing the description of all the resources handled by BTNS and TNS, and the means 
to handle them, such as I/O buffer pools and transport stations 


FNPS tables for each DN7100 (up to 4) connecting the DPS 7 to the network, des- 
cribing the "transport" enabling I/O transfers between GCOS and DNS on one BEeey 
and VCAM on the other side 


- ADM tables for each of the DN7100s concerning GCOS Jepecameites referenced for 
service functions on the appropriate DN7100 


« VCAM tables containing skeletal descriptions of BINS, TNS, FNPS and service 
workstations to be dynamically managed during the communications Session 


» and, MAM/QMON tables containing the description of all queues declared, their 
resource allocations and their structural interface with VCAM. 


For details on the CNC utility, refer to the Network Generation Manual. 
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SECTION III 


NETWORKS CONNECTED VIA THE URP 


The three types of networks connected through the URP, are 

» the URP local network, supported by BTNS 

« the TRANSPAC/URP secondary network, supported by BINS and TNS 
e and, the TNS primary network, supported by TNS. 


For each network, a brief description is given, however, the user-visibility of 
the network in terms of CNC commands, is dealt with in detail. 


Detailed information on the functions of the URP, BINS and TNS is given at the 
end of the section. 
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COMMUNICATIONS OVER BTNS 
The BINS service, on itsS own, only supports the URP local network. This type of com- 
munications involves 
- URP hardware and firmware, UCLA and MLA, respectively 
« and, BINS operating with VCAM. 


URP Local Network 

Handling communications over the URP local network concerns connections between an 
application and the BINS "terminal manager". * 3 

The BINS "terminal manager" functions as follows, 

« the Secondary Network Controller logs on the terminal to the application 

« while the Line Monitor assures the data transfer to and from the terminal. 


A detailed description of BTNS is treated in "Functional Description of BTNS", and 
the URP hardware and firmware is dealt with in "Functional Description of the URP". 


The DSA layers present in the URP local network, are 


« the application layer 


the optional presentation layer which can function both on the side of the appli- 
cation and the BINS "terminal manager"! 


« the session layer serviced by VCAM 

- and, the "link't layer which comprises both the data link layer and the physical. 
link layer, serviced by the line driver of the Line Monitor functioning with oS 
URP. 

Since message routing is not required, the "link" layer has a direct functional in- 

terface with the session layer, thereby bypassing the transport and network layers, 

see page 1-08. 

All objects of the URP local network are visible to the user and are declared by 

the following CNC commands 


LINE, CLUSTER, STATN and TERMNL, for generating the URP secondary network tables 


e IDSEQ, for generating the idseq tables 


GENCOM whose parameters, BITBFSZ/NBBTBF and DABFSZ/NBDABF, are used to generate 
the BINS input and output buffer pools, respectively 


® 


DCTAP, for identifying the application if any terminals are "assigned" to it, the 
exception being TDS which need not be declared with a DCTAP command 


» and, QUEUE, if the queue pertains to a terminal. 

In "Support for Terminals in URP Local Network", the following are to be noted 
e all line procedures, except TC, are shown 

- all terminals supported, except TTY terminals, are listed 


. and, the PVE line procedure for the Mini 6/MFS is included to allow the RBF6/FTF6 
connection to the DPS 7, see page 2-06. 
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Support for Terminals 


in 
URP Local Network 


List of Abbreviations & Mnemonics 


CH : Connection Handler 

1/0 RS : 1/0 Request Supervisor 
LDH : Local Dialog Handler 

LM : Line Monitor 


SNA : Secondary Network 
Administration 


SNC : Secondary Network Controller 


DPS 7 


communications services 


line driver 
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URP (UCLA/MLA) 
MIOS . 
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network 
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COMMUNICATIONS OVER TNS 


TNS functions with URP hardware and ee are to support two types of networks, name- 
ly, 


« the TRANSPAG/URP Secondary network 
e and, the TNS primary network. 


TRANSPAC/ URP Secondary Network 


Communications over this network involves 

- the BINS "terminal manager", for managing the terminals 

TNS, for providing the transport and network services over TRANSPAC 
e and, VCAM. | ; | | 
The two classes of TRANSPAC terminals current ly Supported are 

« PAD terminals, which are TTY and Telex terminals 


e and, CSX25 terminals, which are synchronous terminals that operate through either 
a convertor or terminal concentrator, referred to by the common term "controller". 


The objects of the TRANSPAC/URP secondary network are visible to the user and are 
declared by the following CNC commands 


» PVC, RDTE and RDTN, for generating the transport station (TS) tables 
- IDSEQ, for generating the idseq tables 
« GENCOM whose parameters are 


- BTBFSZ/NBBTBF and DABFSZ/NBDABF, for generating the BINS input and output buffer 
pools, respectively 


- and, PLGNB, for specifying the number of rdtn's connectable over TRANSPACG 
heaueh either PAD or CSX25 


» LSUB, for defining the line over which the wieenal circuit is to be established 
over the TRANSPAC subscription 


» DCTAP, for identifying the application if any rdtn's are "assigned" to it, the ex- 
ception being TDS which need not be declared with a DCTAP command 


- and, QUEUE, if the queue pertains to an rdtn. 


In "Support .for Terminals in TRANSPAC/URP Secondary Network", the DSA layers common 
to both classes of terminals are shown, however the difference in the connection 
mechanism is as follows 


« for CSX25 terminals, the transport layer is implemented by the DSA transport sta- 
tion 


. whereas, for PAD terminals, the network layer interfaces directly with the session 
layere 
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PAD TERMINALS 


PAD terminals comprise the following types of rdtn's connected over TRANSPAC 
through its PAD service, being 


» TTY terminals using either a leased line or a switched network (telephone) 
- and, Telex terminals using the Telex network. | 


Whereas the DPS 7 can call Telex terminals and TTY terminals using leased lines, 
only TTY terminals using a switched network can call the DPS 7. | 


The PAD service enables asynchronous terminals which are unable to generate or re- 
ceive packets in the HDLC line procedure to connect over TRANSPAC. By implementing 
the TTY line procedure, the PAD service functions as a compatibility "adaptor" for 
TRANSPAC and such terminals. It also handles the local dialog to set up the virtu- 
al circuit which corresponds 1i-to-1 with each terminal. 


From the PAD service on the TRANSPAC side, data passes on to the DPS 7 side and is 
handled by the UCLA/MLA and the HDLC driver. 


The modules of both TNS and BINS interact to provide the following consecutive 
functions 


« ENCRM performs two roles, namely 
- allocates the necessary network resources for the virtual circuit established 


- and, reports the demand for the logical connection to the BINS Secondary Net - 
work Controller (SNC) 


Conversely, SNC reports the disconnection demand to ENCRM which then proceeds to 
deallocate the resources. 


e SNC logs the terminal to the application 
» X25L3 exchanges the data record with the BINS Line Monitor (LM) 


The term "record'! is used since the BINS "terminal manager" performs a certain 
amount of presentation control in processing data for removal of control codes. 


- LM transfers the data record assembled as a message to the application. 
PAD terminals are declared by the following CNC commands at network generation 


e RDTE which specifies PAD and the subscription number over which the virtual cir- 
cuit for the rdtn's is to be established 


2 and, RDTN, one or more of which can be "attached"! to the rdte, and is restricted 
to the following rdtn-types : DTU7171, TTU8124, TTU8126 and TTU8128. 


ee 
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CSX25 TERMINALS 


CSX25 terminals are synchronous rdtn's which connect directly over TRANSPAC through 
the intermediary of their "controllers", namely, 


» either the DCU7010 convertor for VIP7001/ 7700/7760, TTS7800 and TTU8221 
e or the TCU7022/ 7043 terminal concentrator for DKU7007/ 7107/7211. 


The difference between the convertor and the terminal concentrator is, that on the 
terminal side, 


- whereas the DCU7010 operates on the VIP line procedure 
» the TCU7022/7043 operates on the HDLC line procedure. 
However, on the side of TRANSPAC, both these "controllers" 


« Operate on the HDLC line procedure for direct synchronous links over the data 
link layer : 


e and, implement the X25 Level 3 part of the network layer, and the transport layer. 
The virtual circuit is established when 

- either the terminal requests access to an application in the DPS 7 

- or the DPS 7 application requests a terminal. 


Once the virtual circuit is established, more than one transport connection can be 
multiplexed over its path. The transport connection is established and negotiated 
between the DPS 7 and the "controller". Each transport connection represents an act- 
ive pair-set of terminal/application. | 


The transport connection is released when the terminal/application pair-set requests 
disconnection. The virtual circuit is released-when the last active transport con- 
nection multiplexed over it, is released, that is, when the last active terminal 
disconnectS. 


Both the network and transport layers are activated at the time of connection. The 
modules of both TNS and BINS interact to provide the Following consecutive func- 
tions 


- X25L3 establishes the virtual circuit 


the DSA transport station (DSA xpt) reports the request for. a transport connection 
which it receives, to the BTNS Secondary Network Controller (SNC) via ENCRM, woe 
take the following consecutive actions 


- ENCRM allocates the necessary network resources for ne transport connection 


- and, SNC completes the logical connection by logging the terminal to the appli- 
cation 


. DSA xpt cumulates all the fragments to constitute the letter and transfers it to 
VCAM via the BTNS Line Monitor (LM) 7 


» LM performs presentation control on the data record by adding or stripping the VIP 
headers and trailers; on output from and input to, the application, respectively. 


CSX25 terminals are declared by the following CNC commands at network generation 


« RDTE which specifies CSX25 and the subscription number over which the virtual cir- . 
cuit for the rdtn's is to be established 


- and, RDTN, one or more of which can be "attached" to the rdte, and ee restricted 
to only the terminals "attached'' to the "controller", not the "controller" itself. 
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TNS Primary Network 
TNS, on its own, only supports the DSA primary network. This ae of communications 
aoises | 

. URP: hardware aaa firmware, UCLA and MLA, respectively 

» and, TNS operating with VCAM. | 


TNS provides a transport service for applications in remote systems to communicate 
“with those in the DPS 7, by | 


- establishing the transport connections 
- administering the network routes 


- and, managing the data link for accessing any remote system configured within Ba 
network. 


A detailed description of TNS is treated in "Functional Description of TNS", and 
the URP hardware and firmware is dealt with in ''Functional Description of the URP". 


The objects of the TNS primary network are visible to the user and are declared by 
the following CNC commands common to both a connection over the TRANSPAC switched 
virtual circuit and a connection over a point-to-point line 


e For the "local" DPS 7 


- LSYS, LSC and LTS, for defining, respectively, the local system, its '"session- 
control" and, its "departure" transport station 


» For the "remote" correspondent 


-- RSYS, RCS and RTS, for defining, respectively, the remote system, its 'session- 
control" and, its "arrival" transport station 


- and, NR, CP and XPRTC, for defining the "access path" linking the lts with the 
rts, in terms of the network route, communications path and transport protocol, 
respectively. 


The transport station of either system functions as the "server'' to its EGeESer 
tive "session-control", 


The differences in the CNC declarations for a switched virtual circuit and a point- 
to-point line are as follows 


- For a switched virtual circuit 


~ LSUB must be present, for defining the LINE over which the virtual circuit is 
to be established over the 'local'' TRANSPAC subScription allowing the lsys to 
“enter' the network | 


- CP must identify the lsub 


- and, RTS must define the "remote" TRANSPAC subscription allowing the lsys to 
"exit"! from the network to connect to the rsys 


© For a point-to-point line 
- CP must define the LINE used for the connection. 
The following CNC commands are mandatory for syntax but not for function, namely 


« PVC, RDTE and RDTN, if a permanent virtual circuit has been subscribed to, in 
which case, they follow LSUB 


. STATN and TERMNL, which follow LINE. 
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NETWORK ROUTE MANAGEMENT 


The two types of network routes are the switched virtual circuit and the point-to- 
point line. Their respective management differs as follows 


- for a point-to-point line, the network route is established waen the line is 
"opened", thereby making the network available 


» for a switched virtual circuit, the network route is established as follows 
- the HDLC driver activates the link by | 
« "opening" the line from the DPS 7 to TRANSPAC 


- and, "calling up" the "remote" subscription number to complete the connection 
to the rts 


- X25L3 synchronizes the DPS 7 with the TRANSPAC switcher for establishing the 
virtual circuit 


- and, ENCRM allocates the necessary resources for the network route. 


More than one network route and, at least two "remote" subscription numbers can be 
declared in the RTS command. The network routes are evenly distributed over the 
subscriptions, and are mapped one-for-one over the virtual circuits. 


TRANSPORT CONNECTION MANAGEMENT 


When the DSA transport station (DSA xpt), which manages the network interface, re- 
ceives a connection request from either the network or VCAM, the transport connec- 
tion is established as follows 


. for a point-to-point line, the DSA xpt directly multiplexes the transport connec- 
tion one-for-one over the network route 


e for a switched virtual circuit, the DSA xpt multiplexes one or more transport 
connections over a network route. | : 


The DSA xpt synchronizes itself with the rts and regulates data flow through the 
transport connection now established. Where two systems are connected over the pri- 
mary through both point-to-point lines and switched virtual circuits, the data flow 
is directed as follows 


» through the network route(s) over the point-to-point line(s) first 


- and, then if any overflow occurs, through the network route(s) mapped over the 
re circuit(s). 
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FUNCTIONAL DESCRIPTION OF THE URP 

The URP communications functions are provided by a set of microprograms for hand- 
ling communications lines. 

Microprogrammed firmware is composed of microprocesses which are 

» the micro-operating system (MIOS) for dispatching a task 


- and, Support management for each type of hardware, which for Oman ECeeLOnss is 
alee referred to as "attachments". 


The components in the URP responsible for implementing communications, are 
- the universal communications line adaptor (UCLA) 


- and, the multiline attachment (MLA). 


Universal Communications Line Adaptor 


The UCLA or "bit machine" is an aggregate of hardware, 1 per communications line, 
in charge of managing the electrical interface according to the transmission and 
connection characteristics of the line connected, namely | 


« whether synchronous, using eae eae timers, or asynchronous, using "start'' and 
"stop" bits 


» and,. whether "dial-up" for switched lines, or leased and local for non-switched 
lines. | | 
The functions of the UCLA are 
« the control of the electrical interface signals 


.» and, the assembly of characters from bits received over the line, and, the disas- 
sembly of characters sent by the DPS 7 into bits. 


Multiline Attachment 
The MLA or "byte machine" is a piece of firmware whose functions. are parameterized 
through tables loaded by BTNS. 


The terminal and line table (TLT) contains tuning, system and, hardware and line 
procedure parameters which are built up as follows 


« parameters not accessible to system software are initialized by ene LPGEN utility 
during URP image generation 


. while parameters visible to system software are initialized with values specified 
in the appropriate parameters of the LINE command at CNC generation. 


Each type of line has its own TLT which contains all the parameters characterizing 
its functions. 


The functions of the MLA are | 
. dispatching tasks to be performed over the different lines 


- and, performing service functions for all the line procedures handled by the URP. 
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Service functions concern the presentation of data being 


« character translation from ASCII (external code) to EBCDIC (internal code), and 
vice versa, from the translation code table (TCT) applicable to the ppooeee: line 
procedure, see note below 


- blocking characters into messapeey by detecting the "end-of-message" indicator. 


- inserting "fill" characters at the end of the line of text on output to allow a 
printer terminal, for example, to perform a "carriage-return" before resuming _ 
printing 7 | 


e and, replacing erroneous characters when. a parity errors occur. 


Note : The TCT is standard for a given line' procedure. However, depending on the 
operational requirements of the terminal(s), the TCT can be altered through 
the TCTNM parameter of the LINE command at network generation, as follows 


« TCTNM=ASCII, for BSC2780 and BSC3270 line procedures, whereby instead of 
ASCII to EBCDIC translation, the external code ASCII remains unchanged 


. and, TCTNM=SPTTY, for TC and TTY line procedures, whereby the Standard 
TCT is patched for additional or substitute "editing" codes. 


Each line procedure has its own support management or "specific attachment" which 
is activated by the MLA for handling its functions, namely 


- polling and selecting, or point-to-point control handling — 
» detecting transmission errors and performing retries 

» detecting terminal and line failures to report to BINS 

. detecting status changes on "timeout"! to report to BTNS 


- and, controlling off-line operations on terminals, such as printing or read/ 
write operations on diskette. 


Most of these operational functions are parameterized through tables dynamically 
updated by BINS at Startup and during the communications session prEoush network 
control commands, namely 


» MTP, for modifying the polling sequence 

e MTL, for modifying the "timeout", read/write ratio and line speed 

-. and, MTE, for editing messages in a terminal-queue. 

The line procedures supported on the DPS 7, are ~ 
F point-to-point : BSC2780, HDLC X. 25, TC, TTY/TTY-R, VIP(A) and VIP(S) 
» and, multipoint : BSC3270, TC, VIP(S). 
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FUNCTIONAL DESCRIPTION OF BTNS 

The functions of BTNS are performed by a monoprocess load module H_BINS which is 
partitioned into two principal modules | 

« the line monitor 


- and, the secondary network controller. 


Line Monitor 


The line monitor is composed of the following functions 
- I/O request supervisor | | 
. line drivers 


« and, terminal drivers. 


I/O REQUEST SUPERVISOR 
The I/O request supervisor 


- dispatches I/O requests and "attention" notifications to either the line driver 
or the secondary network controller, namely 


- input requests sent by the MLA at the end of "read"' channel programs 


- output requests sent by VCAM as a result of "'send's'' executed by the communica- 
tions services 


- and, "attention" notifications sent by the MLA indicating changes in hardware 
status and/or the need for operator intervention | 


» enqueues and dequeues output requests depending on the availability of the lines 
- handles channel programs for data exchanges with the MLA 


e and, maps the activity of terminals on to the DSA session protocol through the 
VCAM interface. 


LINE DRIVERS 


The DSA link layer is implemented by the MLA in the URP and the line drivers. Each 
line procedure, because of its specific characteristics, has its own line driver 
and its own MLA support. 


The line driver 

« generates the frame on output 

e controls the frame on input 

e monitors status changes over the line(s) 

» and, manages the polling of multipoint lines according to 
- line event notifications 


- and, the network control command(s) issued. 
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TERMINAL DRIVERS 


The terminal driver does not represent a single function. It is an activity or a 
set of activities specific to the management needs of a class of terminals. 


The basic requirements for managing the terminal is contained in the terminal con- 
trol block which gives such information as 


- the type and subtype of the terminal either declared at perros generation. Or 
defaulted through specifying an "idseq" at run-time 


» the status of the terminal dynamically set by the BINS "terminal manager"! 


» and, run-time variables entered by the user at the terminal affecting its perfor- 
mance, such as 


The 


either simulating line visibility on the IBM3270 (SML and RML) _ 


or acceptence of small letters as capitals for terminals wehout the "CAPITALS - 
LOCK'' such as Iriscope 200 (RLC and SLC) | 


or allowing the use of the APL character set for the AJ832/833 (APL and NAPL). 
or declaring additional "delete" characters (DC). 


type and subtype of the terminal currently declared at logon allows messages to 


be formatted according to the hardware characteristics, such as line length and 
page scroll, in the case of screen terminals. In the case of managing multidevice 
terminals, the I/O request supervisor is made aware not to send data simultaneously 
to different devices which are not supported: 
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Secondary Network Controller 


The secondary network controller is composed of the following functions 
» local dialog handler 
» connection handler 


- and, secondary network administration. 


LOCAL DIALOG HANDLER 


Local dialog is the exchange of messages between the user at a terminal and the 
BINS "terminal manager''. These messages are 


- either sollicited, involving logon dialog and responses to local commands, such 
as displaying the status of the application(s) 


- or unsollicited, involving broadcasts from the network control operator and in- 
formation on the changes in status of the terminal. 


The logon dialog allows the user to request a logical connection between his ter- 
minal-mailbox and the application-mailbox, see pages 1-24 and 1-29. 


This dialog is conducted according to the physical characteristics of the terminal 
end the connection capability provided, such as whether the terminal is "automatic" 
or manual, and if it has been "assigned" to an application. 


The user, logging on from an interactive terminal, provides the local dialog hand- 
ler with security parameters, being the user-identification and password. 


For further details, see "Establishing the Logical Connection" in the Terminal Op- 
erations Manual. 


CONNECTION HANDLER 


The connection handler manages the VCAM interface and updates the terminal connec- 
tion status within the TCB tables. 


The connection procedure, which involves setting up and maintaining the logical 
connection, can be suspended 


e either at the request of the uSer or on timeout 


- or when the maximum number of authorized connections to the application-mailbox 
has been reached. | | 


If the application-mailbox has been specified with the queueing capability, VCAM 
will queue the request and the connection procedure will resume when a connection 
becomes available on the mailbox. 


The connection handler logs on an "automatic" terminal whenever it is available 
and, if the terminal is "assigned", connects it to the application whenever a con- 
nection becomes available. 


The connection is implemented according to the direction of the request, namely 
» either From a terminal connecting to an application 


» or from an application requesting a terminal. 
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Connection from a Terminal to an Application 


The connection handler prepares all the information needed by VCAM to build the 
"request logical connection" ILCRL, from 


» addressing parameters which are retrieved from the TCB of the eeEeg termi - 
nal-mailbox 


- security parameters which are retrieved by the local dialog handler 


» and, parameters for the dialog and presentation pEorecere: which are retrieved 
eon the TCB tables. 


Once all the information has been gathered, the connection andes requests VCAM 
for @ logical connection. | | | Ys | 


As a result of the negotiation and checking performed by VCAM, VCAM will either 
"accept" or "reject'"' the request, and inform the user at the terminal accordingly, | 
with a local dialog message. 


If the request is "accepted", the terminal is connected to the "destination" ap- 
plication-mailbox. | 7 = a 


If the request is "rejected", the terminal is returned to ene IDLE state and is 
again available for an attempt at a new connection : 


Connection from an Application to a Terminal 
The connection handler 


. identifies the terminal requested by the ebecoce aon Py means of the ILCRL para- 
meters sent by VCAM 


. checks the availability of the terminal, namely, : = 


- whether logically available, for example, a terminal declared as AUTO must be 
in the LOGGED state 


- whether not already connected to another application 


- and, whether -no shutdown is in progress to remove the terminal from the net- 
work configuratione 


The connection handler "accepts" or "rejects" the connection passing on to VCAM 
the necessary parametric values to build the ILCAL. 


If the ILCAL is an "accept logical connection", 
. the terminal is set in the CONNECTED state 


. and, the user at the terminal is informed of the connection with a local dialog 
meSSage. | | 7 


If the request is "rejected", the status of the terminal is not modified. 


SEGONDARY NETWORK ADMINISTRATION 
Secondary network administration involves a variety of functions such as 


» providing the interface to process network control commands and local terminal 
operator commands 


e monitoring the execution of these commands with respect to the status of the 
secondary network objects affected, such as LINE, STATN and TERMNL 


» reporting unsollicited changes in status of network components to the network 
control operator, such as line failures and station availability 


- and, managing the workstation itself, that- is controlling the startup and shut- 
down of BINS. | 


The IOF process associated with the network control operator checks the validity 
and syntax of network control commands. If the command concerns the secondary net- 
work, the IOF process duly notifies BINS which then proceeds to execute the com- 
mand through the secondary network administration function. 


Local terminal operator commands are prefixed by a "break qualifier" which is de- 
fined through the SIMBRK parameter of the GENCOM command at network generation. 

The line monitor scans the input data flow to detect the "break qualifier". Once 
the "break qualifier'' is detected, the line monitor activates the secondary net- 
work administration function to deal with the command. | 


Secondary network administration manages the BINS workstation as follows 


- at Startup, it assumes the activity of the line monitor by simulating an RT com- 
mand on each line which has net been declared CLOSEd at network generation 


e and, at shutdown, it notifies all connected applications of the receipt of the 
TT command and then waits for all terminals to disconnect. 
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FUNCTIONAL DESCRIPTION OF TNS 


The Transport and Network Subsystem is implemented by two processes 


« a network process which is shared with BTNS for implementing the transport and 
network layers 


» and, an administrative process for the asynchronous processing of operations and 
for providing the session interface. | : : 


The network process has a higher processing priority of the two processes. 
TNS provides the support of its DSA layers through the following modules 

- the transport layer is implemented by the DSA transport station (MUX) 

« the network layer is implemented by both X25L3 and ENCRM 

e and, the data link layer is handled by the HDLC driver. 


session layer 


~‘Transporty 
pu Stations] 


| BINS | 
| Terminal | cg 
| Manager | 


In the diagram, the principal features to note are the following 
» TNS modules are shown shaded, the abbreviations being | | 
- ASAM, Asynchronous Access Method 
- MUX, being the "multiplexor" of the DSA transport station 
~ ENCRM, Net work Connection and Resource Manager 
- X25L3, being the TNS module for implementing the CCITT X25 level 3 


~ and, HDLC driver, for managing lines over which the "High level Data Link Con- 
trol" protocol is implemented > 


. and, the presence of the session layer to show the session interface implemented 
directly by TNS acting as the intermediary for the BINS "terminal manager". 
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DSA Transport Station (MUX) 

The transport layer is composed of automata implementing the DSA transport proto- 
col. 

The DSA transport station handles the full DSA transport protocol by 

« Synchronizing itself with remote transport stations 


- eStablishing and disestablishing the transport connection whose status is report- 
ed to ENCRM 


. assembling fragments into letters to pass on to the session layer, and disassem- 
bling letters received from the session layer into fragments 


» and, regulating data traffic passing through transport connections. 
The conveyance of the assembled letters depends on the correspondent, namely 


. if the correspondent is a terminal, the DSA transport station exchanges the let- 
ters through the BINS interface, since the BINS "'terminal manager" is responsible 
for managing the session interface dedicated to terminals 


- however, if the correspondent is a "remote" system in a primary network, the DSA 
transport station directly exchanges the letters with the session layer. 


Network Connection and Resource Manager (ENCRM) 


ENCRM operates on network connections and disconnections, which are demanded by 
either the system or the network. 


The system may request ENCRM to connect 


« either a terminal, in which case, the demand for a network connection will pass 
from the session layer through BINS to ENCRM | 


» or a "remote'' system, in which case, the demand for a network connection is 
routed directly from the session layer to ENCRM. 7 


Conversely, a request coming from the network will be routed to the session layer 
either through the intermediary of BINS for terminals, or directly in the case of 
"remote'! systems. 


When processing a request for a network connection, ENCRM allocates whatever 
network resources are required for the connection to be established by the DSA 
transport station. For example, a request coming from the system is translated as 
a demand from a’ communications service in the application layer. In which case, 
ENCRM allocates specific resources for the service to function. 


A request for a network disconnection passes first to the DSA transport station 
which disestablishes the connection before ENCRM deallocates the network resources. 


ENCRM functions with X25L3 to handle the DSA network protocol. 
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X25 Level 3 

The X25 Level 3 automata, composing in part the network layer, is specialized to 
handle connections over the TRANSPAC public network as follows | 
-» synchronizes the DPS 7 "local!" system with the TRANSPAC switcher — 


» establishes and disestablishes the switched virtual circuit(s) through exchang- 
ing control packets with the TRANSPAC switcher 


. reports the status of the virtual circuit(s) to ENCRM 
. assembles X25 messages from X25 packets, and vice versa (see text pmehlowine) 
» and, controls the flow of data over the virtual circuits. 


The X25 message is handled according to its conveyance and the correspondent con- 
cerned, namely, _ | a 


- in the case where a PAD terminal is concerned, the X25 message is exchanged with 
the BINS "'terminal manager" which manages the session interface for the secon- 
dary network 


e however, if a virtual circuit is used as the transport path, being either the 
network route of a primary network, or an access path to a CSX25 terminal, the 
X25 message is exchanged with the DSA transport station. 


Asynchronous Access Method (ASAM) 


ASAM is an internal TNS process which provides for the asynchronous processing for 
the session and network layers. The intermediate transport layer is not affected. | 


ASAM includes a processor for network administrative commands addressed to TNS, 
namely 


- DT, HT and RT, specifying objects of the primary network 
- MNT, for maintaining tables associated with the primary network object 


e and, "injector'' commands for simulating the session payee in "loop" and "debug" 
modes. 


HDLC Driver 


The HDLC driver handles the data link layer by managing all I/O operations over 
HDLG lines connected to the URP. 


SECTION IV 


NETWORKS CONNECTED VIA THE DN7100 


The three types of networks connected through the DN7100, are 
. the DN7100 local network | 

» the TRANSPAC/DN7100 secondary network 

- and, the FNPS primary network. 

The support of these networks is provided by FNPS. 


For each network, a brief deScription is given, however, the usSer-visibility of 
the networks in terms of CNC commands, is dealt with in detail. 


Detailed information on the functions of the DN7100 and FNPS is given at the end 
of the section. | 
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COMMUNICATIONS OVER FNPS 


The FNPS service functions in tandem with the System Communications Facility (SCF) 
of the DN7100. | 


SCF initializes the logical connection between two correspondents, represented by 
their mailboxes, by determining the DNS task for building the "request logical 


connection'' ILCRL, namely, 


- the device controller task for local and PAD terminals, in which case the device 
controller requests session-control to send the ILCRL 


« or, the transport station task for CSX25 terminals and DSA remote systems, in 
which case, the transport station directly sends the ILCRL. 


When the TPM receives the ILCRL, it pesses it to VCAM which responds with an tees 
cept logical connection"! ILCAL. The logical connection is now established between 


the mailboxes. 


The DPS 7 does not distinguish the origin of. the ILCRL, and as far as it is con- 
cerned, the destination mailbox, | over whatever type of network, is totally trans- 
parent to it. 


For this reason, all terminals in FNPS networks are not declared in the CNC gener- 
atione However, DSA remote systems are declared since each represents a network 
resource which must be known to, and managed by the FNPS service associated with 
the DN7100 to which the remote system is connected. 


The visibility of FNPS networks is therefore restricted to the following CNC com- 
mands 


e FNP, whose parameters define the TPM tables and generate the buffer pools, as 
follows . 


- INBFSZ and INBFNB, for the FNPS input buffer pool 
~ OUTBFSZ and OUTBFNB, for the FNPS output buffer pool 
- FSYS and FSC, for defining, respectively, the DN7100 and its "session-control"! 


- and, RSYS and RSC, in the case of the FNPS primary network, for defining, res- 
pectively, the DSA remote system and its "session-control". 


DN7100 Local Network 


Except for TTY asynchronous terminals, all transmission procedures are handled by 
DCS. However, DCS handles all connection requests whatever the nature of the line 


and transmission procedures. 

The pkoceduce for establishing the connection is in the following sequential order 
» TSV detects the connection request from the terminal 

» the request is passed on to DCS which activates SCF 

» SCF creates the device controller task and activates it 

» the device controller makes a request to session-control 


- and, session-control sends the "request logical connection" ILCRL. | 
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TRANSPAC/DN7100 Secondary Network 


The two classes of TRANSPAC terminals currently supported are 


» PAD terminals, which are TTY and Telex terminals which are unable to generate or 


receive packets in the HDLC line procedure to connect directly to TRANSPAC, and 
hence must use the PAD service aS a transmission interface 


e and, CSX25 terminals, which are connected through either the DCU701L0 convertor 


or the TCU7022/7043 terminal concentrator, and therefore 


- operate on the HDLC line procedure, whatever the VIP or HDLC line procedure is 
used between the terminal and the "controller", for. direct synchronous links 
over the data link layer : 


~ and, implement the X25 Level 3 part of the network layer, and the transport 
layer. 


The explanation for the connection procedure mechanism is illustrated by che. dia- 
gram on the facing page and the following "FNPS Primary Network" diagram. 


The procedure for establishing the connection is in the following sequential order 


e 


TSV detects the connection request over the TRANSPAC network 
the request is passed to DCS which activates SCF 


SCF launches the transport service which, in turn, calls routing management 
(NR Met) 


NR Met manages the network connection request by activating the X25 Level 3 
function (X25L3) 


X25L3 establishes the virtual circuit over which the network route is mapped 


from now on, dispatching the "request logical connection'' ILCRL depends on the 
class of terminal 


~ for PAD terminals : 
: (SCF creates a device controller task and activates it 
e the device controller makes a request to session- control 


e and, session-control sends the ILCRL 


- for CSX25 terminals : 


- SCF creates a transport station task and activates it 
» the transport station (DSA xpt stn) performs the consecutive actions of 
- firstly, establishing the transport connection 


- and, sending the ILCRL. 
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: a | 
FNPS Primary Network 
Since the. DPS 7 is relieved of the transport and network administrative functions 


by the DN7100, it has no Verner yey of the PEsmery network, cf. "URP Connection", 
page 1-0/7. . | 


The transport declared in the FNP Bananne describes the operation of tthe FNPS, ser- 
vice for | 


e mapping the DN7100 over the PSI of the DPS 7 through the FSC command 


e and, attaching all the DSA remote systems associated with it through their res- 
pective RSC commands. 


The concept of the transport station in the context of the FNPS service is only 
figurative, since the DPS 7 does not determine the "access path" to the remote 
correspondents using this connection : 


The real transport station resides in the DN7100 and acts as the "server" for VCAM 
with the FNPS service as the "relay". | 


At the end of this section, functional descriptions of the DN7100 and FNPS are 
treated in detail to show the inter- -relationship between the two sets of communi- 
cations software. 


The procedure for establishing the connection to an application mailbox in a re- 
mote system, is in the following sequential order 


- TSV detects the connection request 
e the request is passed to DCS which activates SCF 


» SCF launches the transport Service which, in turn, calls routing management 
(NR Met) = 


» NR Mgt manages the network connection request according to the connection used 
between the systems, namely 


- for a point-to-point line, NR Met directly establishes the network route 


- for a TRANSPAC switched virtual circuit, the following consecutive actions Oc- 
cur : | | 


e NR Mgt activates the X25 Level 3 function (X25L3) 


- and, X25L3 then establishes the virtual circuit, over which the network 
route is mapped 


once the network route is established, SCF creates a transport station task and 
activates it | 


the transport station (DSA xpt stn) performs the consecutive actions of 


- firstly, establishing the transport connection 


~ and, sending the "request logical connection" ILCRL. 
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FUNCTIONAL DESCRIPTION OF THE DN7100 © 


The DN7100, functioning as a front-end processor, has two physical connections at 
either end 


- on the side of the DPS 7 host, the PSI managed by the 1/0 driver (PIO) of FNPS, 
providing the DN7100 “host support" — 


- and, on the side of the network, the Multiline Controller (MLC) which is 
- managed by the Transmission Supervisor (TSV) 


- and, connected to the network by line adaptors using the various line proce- 
dupes: : 


In the case where the DN7100 is connected to the DPS 7 host over 2 PSIs, each of 
the PSIs must be declared with separate FNPS services. 


The DN7100 handles all the communications management administrative functions, and 
as a consequence, the interface between the DN7100 and the DPS 7 is transport-to- 
session, respectively. 7 


The System Communications Facility (SCF) ass use of the task management and the 
buffer management, provided by the Distributed Network Supervisor (DNS), to handle 
all connections to and from the network. 


The principal components of DN7100 software operated on by SCF, are 
. Links Management | | 
« Terminal Manager 


- and, Transport and Routing Management Services. 


Links Management 


Links Management implements the data link layer and is composed of the following 
modules 


» TSV, which manages the MLC and detects all connection requests over the network 


» and, DCS (Data Communications System), which handles all transmission procedures 
except TTY, and which pr vides the "entry'' to SCF by activating it. 


Terminal Manager 
The terminal manager is in charge of all terminal connections and is composed of 
the following modules 


» Asynchronous Terminal Support, for local TTY terminals connected over switched 
networks 

- Synchronous Terminal Support, for local terminals using line procedures other 
than TTY, connected over leased lines 
« PAD Terminal Support, for PAD terminals of the TRANSPAC network, which uses the 
functions of the Asynchronous Terminal Support and X25L3 

» and, CSX Terminal Support, for CSX25 terminals of the TRANSPAC network, which 
uses the functions of the Synchronous Terminal Support, X25L3 and the DSA trans- 
port Statione | 
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Transport and Routing Management Services 


These are two separate but interdependent services which function | as follows 
« DSA transport station, for implementing the transport layer 


- and, both Network eee ore Management (NR Met) and X25L3, for a the . 
network layer. : 


The DSA transport station performs the following 

e synchronizes the transport stations 

» establishes the transport connection 

- multiplexes several transport connection over the virtual circuit 
- disassembles letters and assembles fragments 

- and, regulates data traffic through the transport connection. 


NR Mgt manages all network connection requests, except for the local network, 
while X25L3 performs the following 


e Synchronizes the DN7100 with the TRANSPAC switcher 
. establishes the virtual circuit 
» assembles X25 messages from X25 packets, and vice versa 


e and, controls the flow of data over the virtual circuits. 
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FUNCTIONAL DESCRIPTION OF FNPS 


- Three GCOS service jobs manage the DPS 7 interface with. the. DN7100, namely 
- the FNPS "transport" service for the "run-time" ‘communications session 


- and, ADM functioning with the NASF "file server" EOF execut ing service functions 
on the DN7100, see pages 2-08 and 2-11. © 7 


FNPS functions with DNS, the system software of the DN7100. The network control 
command "MTF fsys-name AUTO", where "fsys-name'' identifies the DN7100, 


« loads the DN7100 
e and, starts up FNPS. | 


The functions of FNPS are performed by a mono-process load module H_FNPS which is 
partitioned into four principal modules = 


» the transport module, TPM 

» the events manager, TPMEVT | 

« the administrative function, ADCOM 
» and, the i/ 0. driver: PIO. 


Transport Module (TPM) 


The TPM is composed of three functions _ | 
- the VCAM interface which uses session control procedures to dialog with VCAM 


» 'pseudo-transport" management which provides the transport "extension'' from the 
DN7100 to the DPS 7, see the diagram on the facing page 


» and, the logical channel handler which 
- multiplexes different connections over plug numbers of the destinations 
- selects the channel and asks PIO to execute I/O over the channel 
- and, performs I/O operations through channel program management. 


In addition, TPM performs the task of setting. the watchdog timer to ascertain if 
the DN7100 is still active. 

In the case of the DN7100 connection, the transport layer is handled by the DN7100 
while the DPS 7 provides the "pseudo-transport" which the TPM menace see page 
1-07. 

"Pseudo-transport" involves extending the "connection" from the subchannel (SBC) 


to the plug (PLG). The extension is effected through the "port" of the I/O control- 
ler operating over a physical channel of the PSI connecting the DN7100. 


Instead of the logical connection being adjacent to the transport connection, as is 
the case in the URP connection, "pseudo-transport"' is interposed between the two 


connections, cf. page 1-18. 
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$$$ $_____________________. 0SA session protocol ——————————$______________»: 


The logical channel is the path over which a channel program can be executed inde- 
pendently of the others. Several logical channels can be handled over a single phy- 
Sical channel. 


Physical channels are numbered in the PSI, and are categorized according to their 
use, namely, 


- command or control channels, being hardware configured as follows _ 
- channel O, to receive DN7100 status changes and service function requests 
- channel 1, to transmit commands from the DN7100 to the DPS 7 
- channel 2, to transmit commands from the DPS 7 to the DN7100 


. and, data channels, which are firmware defined in the SRST at installation, and 
software configured through the following FNP parameters at network generation 


- the total number of I/0 channels (n) is defined for CCnn, being the SRST exter- 
nal identifier of the associated DN7100 


- the number of I/O channels (s) for SIRIS is defined in MODE, therefore making 
the number of I/O channels available for "native" mode equal to (n-s) 


- and, out of the total number of (n-s) 1/0 channels available for "native" 
mode, the number of channels to be used exclusively for input is defined in 
INCLNB. 


For further details, refer to the Network Generation Manual. 


The numbering of input data channels starts at 3, the next being 4 and so on. The 
numbering of output data channels starts at n, the maximum being 16, the next being 
(n-1) or 15, and So on. 


The fcllowing explanation only deals with the function of the DPS 7 in passing data 
to a remote correspondent, and vice versa, through the intermediary of the DN7100. 
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Events Manager (TPMEVT) | 


The TPMEVT is composed of "exit" routines for each DN7100 configured to the DPS 7, 
for dealing with all incidents occurring in FNPS, such as 


. the termination of the channel program initiated by the logical naan hance 
- and, the termination of FNPS itself. 


The "exit" routine is specific to the incident and, if an anomaly has occurred, the 
appropriate message is displayed on the network control terminal, see message CC14 


of the Network Control Operations Manual. 


Anomalies are generally the result of I/O errors, an FNPS abort or parameters of 
the CNC generation being in conflict with those of the DN7100 "sysgen" declaration. — 


Administrative Function (ADCOM) 


The ADCOM handles the administration of FNPS, name ly 
e processes administrative commands , such as "TT fnp- ~name" 
« initializes the channel program for the logical channel handler 


- and, requests the "'common" system buffer pool manager for peeniocae rss of space, 
and, dynamically frees used segments when no longer required. 


The ''common" system buffer pool manager operates on the I/O buffers declared in the 
FNP command at network generation, that is, for input, INBFSZ and INBFNB, and for | 
output, OUTBFSZ and OUTBFNB. The manager is decentralized since it functions for 
both FNPS and VCAM, and as a result, is not contained within FNPS. | 


I/O Driver (PIO) 


The PIO handles all operations over the channels, namely 

» enables TPM to receive "attention" notifications over command channel O 
» transmits commands from the DN7100 to the DPS 7 over command channel 1 
. transmits commands from the DPS 7 to the DN7100 over command channel 2 


e and, allows input and output exchanges over the data channels. 
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SECTION V 


DISTRIBUTED SYSTEMS ADMINISTRATION AND CONTROL 


Distributed Systems Administration and Control (DSAC) is a component of DSA. It is 
implemented on the DPS 7 as a load-module H_DSAC and as a set of system modules. 


DSAC provides services throughout the primary network, which allow 


» any SsyStem to send a command to another system for execution and to receive the 
resultant response 


e any event occurring within the network to be reported to all participating sys- 
tems 

e and, the participating system to journalize all or some of these events on log- 
files either located locally, that is, on the system itself, or on other remote 
systems. | | 


The command sent from a system can be entered either by the operator as a local 
network control command or through an administrative utility (AUT) using the Ad- 
ministrative Utility Programmatic Interface (AUPI). 


The response as the result of the execution of the command contains the command 
itself and is treated as an event to be Sent over the network. 


The event, such as the opening of the session, a physical line error or statistics 
associated with a virtual circuit, is transited over the network as an unsolicited 


message to be journalized on the logfiles. 


The unsolicited message is vehiculed as a record of specific format and content 
using the Administrative Exchange Protocol (AEP). The AEP governs the exchange of 
such records between a NAD on the one hand and its correspondent on the other hand. [ 


The NAD, node administrative facility, is the active DSAC component and must be 
present in all participating systems. oo 


The correspondent of the NAD can be 

e a network control center (NCC), a network operator interface (NOT) 

« an AUT or an administrative storage facility (ASF). 

The logfiles are a set of files circularly used to journalize unsolicited messages 


in the form of the AEP record. The contents of these logfiles may be processed 
either by the logfile editor (H_LFE), a GCOS utility, or an AUT using AUPI. 


AUPI is a set of system modules which allow AUTs to process administrative traffic 
generated by correspondents of the network. 


DSAC Services 
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- For Release GCOS7 V2, B is not currently supported. | 


A) launching and executing commands on the local system, and receiving the 


responses on the local system 7 


B) launching commands from the local system, executing commands on the re- 
- mote system, and receiving the responses on the local system 


the 


C) launching commands from a remote system, executing commands on the loc- 
al system, and sending the responses to the remote system. | 


Note 3 The front-end processor of: the local DPS 7, if present, is a parti- 


cular case of a remote system. - et = | 


DSAC Services 
Journalization 


remote system 


~G——— direction of unsolicited messages 


1- 
e 


An event occurring throughout the network, in any of the part 
cipating systems, is reported as an unsolicited message in th 


form of an AEP record. 


Note 


A) journalization of events occurring in the local DPS 7 on the logf 


of the DPS 7 itself 


in the local DPS 7 on the logf 


B) journalization of events occurring 
of a remote system 


C) journalization of events occurring in a remote system on the logf 


of the local DPS 7. 


DSAC OBJECTS 


The names of the DSAC objects appear in the equivalent CNC commands for generating 
them in the DSAC configuration. 


The 5 DSAC objects which make up the configuration are 


» AF - administrative function, the active component of DSAC addressed by 1 or 
more mailboxes through which sessions with ACs are established 7 


» AC - administrative correspondent, the direct correspondent of the AF having 
homologous attributes as the AF and, in most cases, being the image of an-- 
other AF . 


e AG -. administrative group, a set of similar or complementary ACs having common 
attributes and functions 


5 Hb "administrative"! filter, associated with ACs, AGs and LGs, for determining 
_if a particular AEP record is to be allowed through | 


e LG - "administrative" log, for providing the AF with the storage facilities for 
AEP records coming from ACs. | 


When CNC is executed, it builds up a set of objects with attributes either impli- 
citly defined by DSAC or explicitly declared by the user. These objects reflect 
the resources of the configuration and its intended use during the DSAC session. 


When the DSAC session is started up, these objects provide the relational links to 
each other for administrative traffic to flow among them 
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DSAG Objects 
Administrative Functions 


semote System, defined by RSYS/RSC or FSYS/FSC 


local anc remote systems 


local system, dezinei by LSYS/LSC 


The term AF is strictly reserved for an administrative function resident in the 
local DPS 7 declaring its DSAC configuration. 


There is no global DSAC configuration but a configuration of each system with res- |= 
pect to the others. - : | s 


The AF and its correspondents are 
» either ''coresident'' if the correspondent resides in the same local system 


» or '"non-coresident"' if the correspondent resides in a remote system 


The front-end System, in the DSAC context, is a particular case of a remote sys- 
teme 
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_ DSAC Objects 
Administrative Correspondents 


Legend : 


AF : local DPS 7 declaring the DSAC configuration 


AC : DPS 6 
DN7100 
DPS 7 


All administrative functions which communicate with a given local AF, whether 


"coresident" or 'non-coresident" with it, are its administrative correspondents 
or ACS. 


ACs are created according to their purpose and function 


« either statically through the associated AC command explicitly defined by the 
user _ = | : | 


e or dynamically by DSAC, as the need to establish administrative connections’ in- 
volving them arises. | — 


All effective communication between the "non-coresident" AC and its AF passes 
via DSA sessions between their respective mailboxes. 


Since the AC is a correspondent throughout the network, its mailbox address takes 
the DSA format <session-name><mailbox-name>. The names of both parameters are 
defined in the AC command. | 
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DSAC Objects 
Administrative Groups 


Several ACs residing in different systems can 


« Share the same functional attributes, such as correspondent type 


e uSe the same filter(s) 
e and, connect to the same AF mailbox. 


Instead of repeating these parameters common to each of the ACs, a convenient way 
is to declare such parameters once for a common "grouping" of ACs. 


This common "grouping" or AG (administrative group) is therefore to be considered 
as the logical extension of each AC belonging to it. . 


The AF-AC connection is established between their mailboxes defined respectively 
e in the AG command, on the one hand 
e and, in the AC command, on the other hand. 


Where the AC is dynamically created, the only user-visibility of such an AC in 
the DSAC configuration is its associated AG. | 
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DSAC Objects 
Administrative Filters 


Some method is required to regulate the flow of administrative traffic through 
the AF-AC "conduit"! in either or both directions, whichever condition applies. 


Administrative traffic passes in the form of the AEP record whose header contains 
filtering parameters which provide the basis on which the record can be selected 


or rejected. 


The administrative filter or FL specifies-filtering criteria which are used to 
match against the filtering parameters present in the AEP record header. The sel- 
ection of the record then depends on the match and the "logic"! of the filter. 


The FL is defined either "input" towards the AF or "output" towards the AC. 


The FL which is an element in the relationship between the AF and its AC, is 

“owned! by : se | 

e either the AG whose filtering criteria apply to all ACs belonging to it 

- or the AC whose filtering criteria, if "enabled", override those specified for 
its associated AG. | | 


The AC which is dynamically created, cannot be declared by the user and therefore 
must have its FL attached to its associated AG. 
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DSAC Objects 
Administrative Logs 


The administrative log or LG represents a set of logfiles used by the AF for 
journalization. 


The LG provides the storage facilities for events occurring in the DPS 7 and 
throughout the network. | 


The LG is a particular case of a "'coresident'' correspondent. 


The connection between the LG and its AF is established through the file manage- 
ment mechanism of the DPS 7. 


Since the LG receives traffic, its associated FL can only be "'one-way'! towards 
itself, that is, "output"! from the AF. 


The AF uses the logfiles on a circular basis, switching from one logfile to the 
next consecutive oOnee | 
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CORRESPONDENT TYPES 


The correspondent type determines how its associated object is to function and 
what service it is to provide. | 


The 5 correspondent types are 


e NAD - 


e ASF - 


e NOI m1 


e NCC - 


e AUT - 


node administrative facility, required in each participant of the DSAC 
configuration and is responsible for taking the appropriate control ac- 
tions within the "node" and reporting its local events to the external 
environment 


administrative storage facility, provides the capability of storing AEP 
records in the local system and transiting them to remote systems, through 
logfile management and administrative libraries 


network operator interface, supports operator and/or administrator connec- 
tions to a set of NADs or AUTs, and translates Control Language Statements 
to/from AEP format 


network control center, contains a mandatory NOI and is composed of AUTs 
attached to it through the AEP or across a local programmatic interface 


(AUPT) 


administrative utility, a batch or real-time application using DSAC ser- 
vices; a user-defined AUT uses AUPI. 


Overview 
of 
Correspondent Types 


NAD 
-AF licczl DPS 7 
ASF | 


local | 
DPS 7 NAD 


Legend : 
* DPS 6 : NCC and non-NCC co 
§ DPS 7 : loce) and remote | 


Unless indicated "local", all systems 
are to be considered "zemote" 
DPS 7 


NAD 


Each correspondent type performs specific functions. In the current release, the 
AF in the local DPS 7 performs the functions of NAD and ASF. 


Connections between the correspondent types are shown for some of the different 
systems that make up the DSAC environment of the DPS 7. 


The systems that appear in the DSAC configuration, are those known to CNC through 
the PROFILE parameter of their a aca RSYS commands. LSYS and FSYS "profiles" 


are subsets of RSYS "profiles". 


Not all configured systems implement the functions of all the correspondent typese | 


There is no logical or operational reason why all participating systems of the 
DSAC configuration should not fully implement all the functions. 


This is a limitation imposed on the system by its current state of software deve- 
lopment and not a DSAC architectural restriction - 
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OVERVIEW OF DSAC IMPLEMENTATION 


The administration and control of distributed systems depend on the flow of infor- 
mation between participants of the network. Each participant is therefore aware of 
any event happening in its counterparts throughout the network, and can conse- 
quently take effective measures. | 

DSAC is implemented by the DPS 7 in terms of 

e connections to its NAD (AF LNAD) 


« and, connections to its ASF (AF DSALOG). 


Connections to AF LNAD- 


The AF LNAD has the system-reserved mailbox $NAD. It is a unique occurrence whose 
State is always "'enabled", 


Correspondents of LNAD can be an NCC, NOI, AUT or AC ASF. 


LNAD interacts with its correspondents as follows, 
~~ receives CMDs from the NCC, NOI and AUT 


e takes the appropriate control actions, and sends back the resultant RSPs to the 
respective originators of the CMDs 


e and, informs the NCC, NOI and AC ASF of events occurring in the local system 


Connections to AF DSALOG 
The AF DSALOG has the system-reserved mailbox $LOGFILE. It is a unique occurrence. 


Its state can be altered by the operator from "enabled" to "locked", and vice ver- 
Sae "Locking'! DSALOG merely stops the journalization. of UMs. 


DSALOG provides the DPS 7 with DSAC storage facilities, as follows, 
e receives UMs from AC NADs, both local and remote 


e and, journalizes these UMs on the set(s) of logfiles associated with the LG. 


‘The "non-coresident" correspondents of DSALOG are remote NADs which are dynamical- 
ly created. | 
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JOURNALIZATION 


There are 2 sets of logfiles, each of which are | composed of up to 9 UFAS files, 
e the mandatory SYS. DSALOGi set 

» and, the optional user-defined SYS. < lg- name>i- sete 

Journalization consists of 2 activities, namely 


e local journalization which involves the DPS 7 logging on its set(s) of logfiles, 
UMs produced not only by itself but also UMs produced by remote NADs 


e and, remote journalization which involves the DPS 7 sending only the UMs it pro- 
duces to the remote ACs to be logged by their storage facilities. 


Local Journalization 


AF DSALOG receives UMs and RSPs from the est NAD (AC LDSALOG) and Poe remote 
NADs (dynamic ACs of AG RDSALOG) 


AF DSALOG stores this administrative data on its set(s) of logfiles. 


UMs from LDSALOG represent events occurring in the local DPS 7 and can be filtered 
before being sent to AF DSALOG An internal interface between AF DSALOG and 
AF LNAD allows these UMs to transit to the remote AGS. 


UMs from RDSALOG are not sent to remote ACs. 


If any NCC, NOI or AC ASF connect to the local DPS 7, UMs from LDSALOG are tran- 
sited to them and stored EnEE Deere? at the same time on the mandatory set of log- 
files SYS. DSALOGi. es - 


Filters associated with these logfiles are ignored. ‘The UMs sent to the remote ACs 
are therefore a facsimile of those stored on SYS. DSALOGi. 


When all remote ACs to which UMs are sent, disconnect, the filters associated with 
SYSeDSALOGi are once again taken into account. 7 


Whether remote ACs connect or not, UMs can be filtered and stored only on the op- 
tional user-defined set of logfiles SYS.<lg-namei.. 


Remote Journalization 


~ 


Remote journalization involves the transit of UMs generated by the local NAD 
(AG LDSALOG) to the NCC, NOI and AC ASF, when they connect to the local DPS 7. 


UMs from LDSALOG include the results of the sues and execution of CMDs sent 
to AF LNAD by the NCC, NOI and AUTs. 


While the originator of the CMD receives the RSP, the NCC, NOT aud AC ASF even- 
tually receive the same information vehicled as a UM, when their filters accept 
such records. 


Whatever affects local journalization also affects remote journalization.e If ei- 
ther AF DSALOG or LDSALOG is "locked", UMs are no longer sent to the remote ACs. 


Since the AF LNAD continues to function in the meanwhile, all events occurring in 
the local DPS 7 are not recorded and are therefore "lost", 
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Use of Filters during Journalization 


All journalization is based on the entry of UMs generated by the local NAD 
(AC LDSALOG). 7 


Before being sent to the AF DSALOG, these UMs can be filtered by LDSALOG itself. 


Once AF DSALOG receives the UM from LDSALOG, it dispatches the UM to 


« both the mandatory SYS.DSALOGi logfiles and the optional user- ~defined logfile 
set SYS.<lg-name>i, if present 


e and, NCC, NOI and AC ASF, if any of these remote ACs connect to the local DPS 7. 


Filters associated with SYS. DSALOGi logfiles operate as follows 


- they are effective for UMs coming from LDSALOG Bras that no remote ACs con- 
nect to the local DPS 7 (AF LNAD) 


« however, they remain effective for UMs coming from remote NADs (AG RDSALOG) ies 
ther remote ACs connect or not. 


Filters associated with SYS.<lg-name>i logfiles remain effective whatever the or- 
igin of the UM and whether remote ACs connect to the AF LNAD or note 
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OPERATING THE DSAC SESSION 


The 5 network control commands for operating the DSAC session are 
« ST DSAC, for starting the session 

« TT DSAC, for terminating the session 

« HT <object-name>, for "locking" the object 

« RT <object-name>, for "enabling" the object 


« and, DT <object-name > [< parameters >] » for displaying the status of the ob- 
ject. | 


The DSAC session is started up after the communications session is started up be- 
cause the transport connections between the DPS 7 and its remote systems must 
first be activated before the administrative connections between them can be est- 
ablished. | 


Journalization begins once the DSAC session is started upe The management of the 
logfiles and the flow control of administrative traffic during journalization are 
monitored through network control messages displayed to the operator. 


All DSAC objects declared in the configuration are either "enabled" or '' locked". 
As far as the user is concerned, these are the only declarable and alterable 
States. Depending on the requirements of the DSAC environment, the operator can 
dynamically alter the state of the object before the start of, and during the DSAC 
sessione 


The HT and RT commands respectively "locking" and "enabling" the object, do not 
need the DSAC session to be started up, to be effective. 


However, during the course of the DSAC session, the system itself can dynamically 
alter the state of the object to that previously set either in its CNC state or, 
subsequently, by the operator. 


~The operator can actively monitor the status of the object through DT commands. 
The status of the object comprises its state, its correspondent type and its asso- 


ciation with its correspondent. 


Not all error conditions require operator intervention. For example, although the 
operator is» informed of a temporary overflow situation, the system takes its own 
recovery actionSe 


Error conditions which require operator intervention, are denoted in the message. 


The DSAC session is terminated before the shutdown of the communications sessione 
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ADMINISTRATIVE UTILITIES PROGRAMMATIC INTERFACE 


AUPI is the programming interface for utilities which process administrative data 
of a DSA network. 


AUPI enables the user through the AUT to connect 


» to any system, local or remote, to issue commands for execution, and to receive 
the resultant responses 


e to the LG object of the local DPS 7, in order to obtain "on-line"! information 
on statistics, events and command responses, as they happen 


e and, to the set of logfiles for the same information as above, but "off-line", 
the logfile being processed as any file in Paben notes 


AUPI is implemented as a set of call procedures, each uSing its ebectitc, data 
Sstructure(s).e AUPI is available in COBOL and GPL. 


It sentouis to applicable DSA standards and allows 


e the simplication of AEP encoding techniques by providing the user a high- lagel 
view of this protocol 


« and, user-defined AUTs to be independent of changes in the structure and form 
of Ee AEPe 


For further information, see the AUPI User Guide. 
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BASIC NETWORK SESSION EXERCIZER 


BNSE is a tool for testing the session and application layers between two systems — 
in a DSA-300 network. 


It operates on the basis of one system being the "initiator" and the other being 
the "acceptor". The session is established between the mailboxes of both systems 
under test. The subsequent transfer of data during the test session, does not dis- 
rupt normal network traffice 


BNSE is implemented as a packaged product. 


It is started as a job through the SJ console command, in which parameters for the 
job execution are entered. 


In the facing diagram, the local DPS 7 is shown dialoging with two remote systems 
using the default mailboxes of the respective "initiator" and "acceptor" tests. 


For further information, see the DSAC User Guide. 
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APPENDIX A 


ACCESS OVER TRANSPAC 


TRANSPAG is the X25 packet-switching public network available in France. The two 
types of subscriptions that can be taken out with the PIT are 


- either the packet mode for connecting the DPS 7 to the TRANSPAC network 


« or the character mode for connecting a-TTY terminal via the PAD service to the 
DPS 7. . % pe | 


An explanation of how to complete the subscription form and the relationship be- 
tween the entries and their associated CNC parameters are given in the Network Con- 


trol Operations Manual. 


A-01 | 


DESCRIPTION OF THE TRANSPAC NETWORK 


The TRANSPAC network is a set of switches, each one being duplicated with a "back- 
up'"' switch, interconnected by high-speed HDLC lines. It is the common carrier of 
the French PTT, which provides virtual circuits of the X25 packet-switching network. 


A subscriber is any correspondent of the network, being 
- either a terminal or a cluster of terminals in a secondary network 
- or a system, being a central processor, in a primary network. 


The HDLC line which connects these correspondents can be either medium speed (2400 
bps) or high speed (48000 bps) depending on the throughput required. 


The link protocol over the TRANSPAC network uses the HDLC line procedure. Systems 
that transmit in the HDLC line procedure, and terminals attached to "controllers" 
that adapt to the HDLC line procedure, can ‘connect directly over TRANSPAC. 


Telex and Teletype terminals must ‘use the PAD (packet assembler/disassembler) ser- 
vice that adapts their TTY line procedure to the HDLC line procedure, to connect to 
TRANSPAC. Asynchronous TTY lines operate at low speed, 


All correspondents connect to a switch which acts 
e either as a "shunt" to directly establish the "link-up" 
- or aS a "relay'' through other switches before establishing the "link-up". 


The correspondent is unaware of the mechanism of the "link-up". What the correspon- 
dent is aware of, is the access to the destination required. 
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Virtual Circuits 


Communications between two subscribers is handled over a virtual circuit payee 
by TRANSPAC., | 2 : 


The virtual circuit establishes the logical path between the subscribers, over 
which one cor more network routes defined by the uSer, are mapped. 


The effective throughput of the virtual circuit is determined by the user through | 
the following attributes specified by their respective parameters 


» Speed of transmission specified by the LINESPEED parameter at URP firmware gene- 
ration | | | 


e packet size which fixes the size of the packet to be exchanged, specified by the 
PKSIZE parameter of the LSUB. command at CNC generation 


e and, the authorized anticipation, being the maximum number of packets that the 
subscriber may send before TRANSPAC acknowledges the first packet transmitted, 
specified by the WINDOW parameter of the LSUB command. 


While these parameter values may differ for communicating subscribers, TRANSPAC 
ensures that the lower value relevant to the exchange transmission between any two 
subscribers at a time is selected for consistency and compatibility. 


A virtual circuit is established through the exchange of control packets conform- 
ing to the TRANSPAC connection protocol. . , 


Once the connection is established, t the virtual circuit is set up over a physical 
path linking the subscribers through a series of switches. The physical path need 
not necessarily be the same between two subscribers. TRANSPAC "routes" the virtual 
circuit through available switches most expedient to the current transmission. The 
subscriber, however, is unaware of the mechanism of this "routing". . 


The virtual circuit may be 


» either permanent, where the pvc is permanently available, in which case, the pvc 
must be declared in the CNC Bevererten by the command sequence PVG - RDTE - RDTN 
following the LSUB command 


» or switched, where the svc is made available only on request, in which case, the 
user visibility of the svc's is restricted to the SILIN, SOLIN and SLINE parame- 
ters of the LSUB command to indicate respectively 


- the number of svc's dedicated to inward calls 
-~ the number of svc's dedicated to outward calls 
_- and, the number of "general-purpose' svc's for inward and outward calls. 


The rules governing the physical path over which the virtual circuit is set up are 
as follows 


. the path once set up remains unchanged until the virtual circuit disconnects, 
with the result that packets exchanged over the virtual circuit will follow the 
Same consecutive order at emission, as at reception 


» in the case of a switch failure when the path has already been set up and before 
the virtual circuit disconnects, an alternative physical path is automatically 
set up and packets already transmitted over the previous path will be retrans- 
mitted over the current path to preserve and maintain their consecutive order 


. and, the choice of the physical path depends on the resources reserved in each 
switch to cater for the speed of transmission and the authorized anticipation. 


Subscriber and Subscription 


A subscriber, being any correspondent, is a TRANSPAC user identified within the 
network by a "dial-up" subscription number which can be either a 7-digit telephone 
number or a number of up to 15 digits known specifically to TRANSPAC. 


The subscription number is declared in the appropriate CNC command(s) depending on 
the subscriber 


- if the subscriber is a terminal declared by the RDTN command, the subnb is de- 
clared as the argument of the SUBNB parameter of the preceding RDTE command 


- if the subscriber is a system declared by the RSYS - RSC command sequence, two 
subnb's are required to establish the link-up between the "local system" and the 
rsys, as follows 


- for the lsys : 


» the "local subnb'" is declared as the argument of the SUBNB parameter of the 
LSUB command 


- and, the name of the LSUB command is declared as the argument of the SUBSCRID 
parameter of the CP command defining the communications path between the lsys 
and the rsys 


- for the rsys : 


- the "remote subnb"' is declared as the argument of the ADDR parameter of the 
RTS command which defines the "arrival" transport station of the rsys. 


The subnb is an addressing parameter which allows one subScriber to call up another 
and which is associated with the following attributes 


_« the number and characteristics of the virtual circuits available 


. and, the physical X25 HDLC link(s) interposed between the subScriber and its as- 
sociated switch. | 


The logical connection between two subscribers can be maintained through different 
links according to the availability of the intervening switches. The higher the 
performance requirements, the more virtual circuits are needed to support the logi- 
cal connection. AS a consequence, a subscriber taking out several TRANSPAC sub- 
scriptions and declaring several network routes per subscription, over which the 
virtual circuits’‘are mapped, can maintain a high transmission throughput by enabl- 
ing different access points to different categories of remote subscribers. 


However, the hardware contraint imposed by the network is that the failure of a 
switch and its backup makes unavailable all the subscriptions linked to it. The way 
to get around this contraint is to open a backup subscription which uses a differ- 
ent switch. It is highly improbable that both switches and their backups can fail 
simultaneously. 


Packets and Packet -Swit ching 


The packet is the unit of information transported over the virtual circuit and con- 
tains control information concerning Boo prorecelss used ey TRANS PAC to manage the 
virtual circuits, such as | | 


- routing information being the reference for the packets following > 


» the rank of the packet within the X25 message to which it peas determining 
the order of the packet in relation to its succession 


° acknowledgement information 


- the amount of information transported in the packet, thereby determining the size 
of the packet 


- and, the type of packet which determines the purpose of the information trans- 
ported, whether for control or as uSer data. 


The relationship of control information to data information is illustrated by the 
contents of the "request logical connection" ILCRL which is generated in the ses- 
Sion layer to set up the logical connection over the virtual circuit, as follows 


. at the level of the session layer, the contents is control information 


» however, at the level of the TRANSPAC network, the contents is data information 
since the purpose of the packet is unknown to TRANSPAC which acts solely as a 
conveyancing" agente 


The packet size within TRANSPAC is one of 32, 64, 128 or 256 bytes, exclusive of 
any control information that is added en route. if the packet size is not declared 
in the PKSIZE parameter of the LSUB command, TRANSPAC takes as default a packet 
Size of 128 bytes. 


TRANSPAC uses the packet-switching technique. A user message or MUX data fragment 
sent over a virtual circuit is split into packets. The last packet, though not 
completely filled, has to conform to the same fixed length as determined at connec- 
tion time, as the rest of the preceding packets. 


On the receiver side of the virtual circuit, the packets are received in the same 
order as sent, and, being physically-adjacent and logically consecutive, can be im- 
mediately reassembled into the X25 message. The X25 message, in turn, is reconsti- 
tuted into either the user message or a MUX data fragment. 


The X25 or DSA transport station is responsible for © 
% managing the virtual circuit 

e assembling packets into letters on reception 

e and, disassembling letters into packets for emission. 
The advantages of the packet-switching technique are 


. reliability of transmission since the message is broken down into packets, and, 
error detection being at the level of the packet, a sequence of packets and not 
the entire message need be retransmitted 


. high throughput performance of the network since the switches are linked through 
high speed X25 HDLC lines and since the routing of the virtual circuit is dynam- 
cally selected according to the immediate availability of the switches. 


Features of the Packet-Switching Network 
The following are the principal features of TRANSPAC 


- the error rate tends to be low since any error is detected at the level of the 
packet whose size, even at a maximum of 256 bytes, is relatively small in compar- 
ison to the average message, and, therefore, the error is recovered on retrans- 
mitting the packet and not until the entire message is sent 


» easy memory management at switch level is due to pre-determining the size of the 
packet thereby enabling simple fixed algorithms to be applied to allocate memory 
resources 


Since the unit of transmission is the packet, any subscriber, with enough infor- 
mation to fill a packet, can immediately start transmitting, although at the time 
of the transmission, the letter has yet to be completed 


while the subscriber is restricted to a pre-determined packet size, the same vir- 
tual circuit can transmit packets of differing sizes between subscribers, each 
declared with its own packet size to compensate for transmission at different 
speeds. 


PAD Service 


The PAD service enables asynchronous TTY terminals to connect to the TRANSPAC net-~ 
work by providing them the means of generating and receiving packets using the HDLC 
line procedure over either switched or leased lines. 


It manages the local dialog in order for the subscriber to set up the virtual cir- 
cuit. 

An asynchronous terminal connected to PAD is declared at network generation by 

« the keyword PAD in the RDTE command | 

e and, the type DTU7171, TTU8124, TTU8126 or TTU8128 in the following RDTN command. 


Since the PAD terminal is seen as a mono-virtual circuit subscriber by TRANSPAC, 
each terminal is declared by a pair-set of CNC commands RDTE-RDTIN on a 1-for-1 de- 
claration. 


By contrast, in the case of a CSX25 terminal, being either VIP or QUESTAR, it is 
its "controller" which is seen as a mono-virtual circuit subscriber by TRANSPAC, 
The "controller" which is declared by the keyword CSX25 in the RDTE command, can 
therefore be followed by several RDTN commands representing the terminals -associa- 
ted with ite 
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